O que vem depois do Kubernetes?

“Entediante”. Esse é um dos melhores elogios que você pode dar a uma tecnologia de infraestrutura. Ninguém quer executar seus aplicativos de missão crítica como “picante!” Mas chato? Chato é bom.

Entediante significa que uma tecnologia atingiu um certo nível de onipresença e confiança, que é bem compreendida e facilmente gerenciada. Kubernetes, em produção em 78% das empresas, passou sem dúvida nesse ponto, tendo sido amplamente reconhecido como um encanamento padrão que possibilita a nuvem que “simplesmente funciona”.

Ou, dito de outra forma, tornou-se “chato”.

Mesmo que a Cloud Native Computing Foundation ajude a coordenar o desenvolvimento de uma série de outros projetos para preencher os espaços em branco deixados pelo Kubernetes na camada de infraestrutura, a conversa sobre o Kubernetes começou a mudar para o que está acontecendo no topo da pilha. Em abril, Kelsey Hightower observou que o Kubernetes resolve apenas metade do problema na modernização de aplicativos, se:

Há muito esforço tentando “modernizar” aplicativos na camada de infraestrutura, mas sem investimento igual na camada de aplicativos, pense em estruturas e servidores de aplicativos, estamos apenas resolvendo metade do problema.

O que fazemos sobre isso?

Preenchendo a lacuna entre aplicativos e infraestrutura

“Há uma enorme lacuna entre a infraestrutura e a criação de um aplicativo completo”, disse Jonas Bonér, CTO e co-fundador da Lightbend, em entrevista. Bonér ajudou a iniciar o projeto de código aberto Akka, que visa solucionar um complexo problema definido entre a infraestrutura e o aplicativo, acima do Kubernetes na pilha. Como Bonér colocou:

“É um exercício para o programador preencher essa enorme lacuna do que realmente significa fornecer SLAs para os negócios, tudo o que é difícil em sistemas distribuídos, mas necessário para a camada de aplicativos aproveitar ao máximo o Kubernetes e seu ecossistema de ferramentas.”

É aqui que uma organização precisa de coisas que ficam entre o aplicativo e a infraestrutura e fazem com que tudo funcione, continuou Bonér. Não se trata de substituir nada, mas de adicionar mais ferramentas na caixa de ferramentas e estender o modelo de infraestrutura de isolamento e restrições impostas pela rede ao próprio aplicativo – entregue em um modelo de programação intuitivo, flexível e poderoso, mas simples.

Como dois engenheiros da Tesla discutiram em uma conferência no ano passado, a Tesla conta com recursos de “gêmeos digitais” que alimentam sua rede elétrica, possibilitada pela combinação de Akka e Kubernetes. “A maioria dos nossos microsserviços opera em Kubernetes, e o emparelhamento de Akka e Kubernetes é realmente fantástico”, disse o engenheiro da Tesla, Colin Breck. Ele explicou:

O Kubernetes pode lidar com falhas de granulação grossa no dimensionamento, de modo que seriam coisas como escalar pods para cima ou para baixo, executar testes de animação ou reiniciar um pod com falha com um retorno exponencial. Em seguida, usamos o Akka para lidar com falhas refinadas, como interrupção do circuito ou repetição de uma solicitação individual e modelagem do estado de entidades individuais, como o fato de uma bateria estar carregando ou descarregando.

De acordo com Bonér, existem três áreas geralmente não resolvidas que ainda estão evoluindo acima do Kubernetes na pilha nativa da nuvem, dando origem a novas abstrações oferecidas por tecnologias como Akka: composição da camada de aplicativo, casos de uso com estado e casos de uso de dados em movimento.

Habilitando a composição declarativa da camada de aplicativo

“As pessoas costumam usar ferramentas, hábitos e padrões antigos, geralmente originários dos projetos tradicionais (monolíticos de três camadas) que inibem e restringem o modelo de nuvem fornecido pelo Kubernetes”, observou Bonér. Precisamos estender o modelo “incrivelmente bom” de contêineres, malhas de serviço e orquestração até a lógica do aplicativo/negócios, para que possamos tirar o máximo proveito dele, mantendo as garantias de ponta a ponta em nome da aplicação, ele disse.

O Serverless mostra o caminho aumentando o nível de abstração e fornecendo um modelo declarativo onde o máximo possível de clichê, infraestrutura e operações é removido e gerenciado pela plataforma, deixando o desenvolvedor com a essência: a lógica de negócios e seu fluxo de trabalho.

Melhorando o Suporte para aplicações stateful

A maior parte do ecossistema de nuvem está lidando principalmente com os chamados aplicativos de estilo de 12 fatores, ou seja, aplicativos stateless. Às vezes isso pode ser tudo o que você precisa. Mas aplicativos não triviais são geralmente uma mistura de casos de uso stateful e stateless.

“Precisamos de mais e melhores ferramentas para enfrentar bem o stateful“, disse Bonér. “Atualmente, o valor está frequentemente nos dados, e é nos casos de uso mais estáveis que reside a maior parte do valor comercial – garantindo que você possa acessar esses dados rapidamente, garantindo a correção, consistência e disponibilidade”.

Na nuvem, a menos que você tenha um modelo realmente bom e as ferramentas que o suportam, você será forçado a voltar à arquitetura de três camadas, inserindo tudo no banco de dados todas as vezes, independentemente de comunicação, coordenação ou tempo de armazenamento de estado a longo prazo.

É importante ressaltar que você também precisa de bons modelos stateful para complementar a abordagem stateless, oferecendo mais opções na caixa de ferramentas. Atualmente, a extensão do manuseio de casos de uso stateful do Kubernetes é realmente suportada apenas no recurso StatefulSets, mas o StatefulSets é projetado para as pessoas que implementam infraestrutura como bancos de dados, observou Bonér, não para os desenvolvedores de aplicativos.

“Portanto, ainda existe uma enorme lacuna aqui”, disse Bonér. “É aí que a Akka realmente entra”.

Manipulação de dados rápidos ou casos de uso de dados em movimento

Indiscutivelmente, o ecossistema Kubernetes ainda não oferece grande suporte para streaming e casos de uso baseados em eventos. Malhas de serviço como o Istio são projetadas em torno de um modelo de solicitação-resposta e “podem atrapalhar”, disse Bonér. O streaming também costuma ser estável, com estágios que agregam dados na memória enquanto precisam estar disponíveis, o que se vincula à discussão acima. O trabalho está em andamento na comunidade Knative para resolver isso, mas estamos apenas começando, sugeriu Bonér.

Grande parte do impulso dessas novas direções parece ser o baixo código/nenhum código/“dissocia o front end do back end” que se acumulam sob o movimento sem servidor.

“Sem servidor nos aproxima de resolver o problema de estender o modelo do Kubernetes para o próprio aplicativo”, disse Bonér. “É disso que se trata. Abstraindo o máximo possível e migrando para um modelo declarativo de configuração em vez de codificação, onde você define o que deve fazer e não como fazê-lo”.

Infraestrutura de aplicativos que “simplesmente funciona”

À medida que a pilha nativa da nuvem continua a evoluir acima do nível de infraestrutura do Kubernetes, será interessante ver como esses conceitos na camada de aplicativos funcionam para atender a desenvolvedores de linguagens específicas. Embora muitos dos desafios mais difíceis da arquitetura de aplicativos tenham sido o domínio do desenvolvimento Java do lado do servidor, parece que estamos nos movendo para uma arquitetura Jamstack, onde cada vez mais os desenvolvedores JavaScript esperam acessar a infraestrutura de aplicativos que simplesmente funciona, especialmente quando os pontos de extremidade se multiplicam exponencialmente.

Isso não sugere que a infraestrutura de back-end não seja importante. Em vez disso, é reconhecer, como Ian Massingham argumentou, que os desenvolvedores front-end superam em muito os desenvolvedores back-end, e por boas razões: Há muito mais aplicativos que precisam ser construídos do que infraestrutura que precisa ser criada para hospedar isto. Conectar os dois mundos através de projetos de código aberto como o Akka se torna cada vez mais importante.