Serviços de aplicativos para aplicativos Kubernetes: O mesmo velho novo

Há um longo caminho entre a solução de problemas do VMS VAX e a criação de microsserviços sem servidor (embora, com o anúncio do suporte ao COBOL no AWS Lambda no re:Invent, a primeira volta da lemniscata de TI possa estar completa).

Muitas coisas mudaram ao longo do caminho. Acho que me lembro de conseguir hackear scripts em Perl e ficar irritado com um sistema operacional que permitia que você mudasse o diretório para algum lugar que não existia (bônus: ele permitia que você o criasse quando estivesse lá). Agora parece que você pode gastar tanto tempo decidindo a abordagem para resolver um problema quanto realmente resolvendo-o. E isso é fantástico. A variedade de arquiteturas, o ritmo de desenvolvimento, a oportunidade digital e a liberação da criatividade dos desenvolvedores que todos os novos brinquedos estão nos dando são ótimos. Não importa de que lado do arco do proscênio você esteja, tanto construtores quanto consumidores estão aproveitando aplicativos novos e melhores a uma velocidade e funcionalidade que eram propriedade da ficção científica há não muito tempo.

Os contêineres e seu vigilante controlador Kubernetes são um exemplo pertinente. A tecnologia de contêineres tem sido, sem dúvida, um acelerador fundamental da explosão do desenvolvimento de aplicativos.

Esta semana, na ensolarada Seattle (às 10h46 do dia da redação deste texto [Atualização – ainda ensolarado às 13h36]), mais de 8.000 pessoas estão se reunindo para conversar, ouvir e aprender sobre o Kubernetes e outras tecnologias de código aberto. A mistura de conversas, aprendizado prático e estimulantes é a sopa primordial da inovação. Enquanto você lê isso, 12 grandes ideias novas (e 37 terríveis) terão surgido.

Alguns desses aplicativos mudarão vidas, alguns inovarão a arquitetura, alguns desenvolverão interfaces de usuário e alguns provavelmente serão apenas mais uma maneira de ilustrar o quão desconectado estou da cultura jovem.

Mas algumas necessidades unirão essas diversas aplicações e as estruturas que elas usam. As soluções podem parecer diferentes, mas há componentes críticos que todos precisam resolver:

Escala – Se você quer ter sucesso, precisa ser capaz de crescer ao longo do caminho (e provavelmente voltar a crescer ocasionalmente).

Estabilidade – Todos os aplicativos precisam de um nível apropriado de estabilidade – desde "passar pela demonstração no palco" até requisitos de tempo de atividade com risco de morte.

Segurança – Pessoas más existem e, às vezes, elas atacam seus aplicativos. A complexidade dos sistemas modernos parece aumentar incessantemente a área de superfície de ataque com a qual você precisa se preocupar.

Observabilidade – Ver para crer, o que é duplamente importante quando há um problema. Levar as informações certas da camada OSI para as pessoas certas rapidamente pode ajudar você a falhar menos, se recuperar mais rápido e tornar o mundo "você constrói, você executa" um pouco mais confortável.

Essas necessidades não são terrivelmente únicas, mas continuam sendo as preocupações fundamentais que precisam ser abordadas por todo aplicativo bem arquitetado, de preferência antes que se tornem um problema e antes que uma linha de código seja escrita.

Meu estimado empregador, a F5 Networks, construiu um negócio multibilionário que atende a essas necessidades e, honestamente, somos muito bons nisso (mas eu diria isso). Chamamos de serviços de aplicação as coisas que fazemos para atender a essas necessidades. Serviços de aplicativos que protegem o tráfego de aplicativos, o inspecionam e o direcionam. Serviços de aplicativos que encaminham clientes para o lugar certo, serviços de aplicativos que extraem, encaminham e exibem a telemetria principal do aplicativo. Esses são os principais serviços que mantêm os aplicativos dos nossos clientes funcionando – e são o tipo de serviço que os aplicativos continuam precisando, não importa onde ou como sejam criados.

Voltando ao discurso de um fornecedor?

Até agora, tudo bem, ‘um velho rabugento tentando me convencer de que sua tecnologia da velha escola ainda é relevante’. OK, então aqui está o que virou, girou no ar e caiu de cabeça para baixo. Vamos começar com o mais importante: A maneira como os serviços são implantados.

Uma das tecnologias facilitadoras por trás da adoção de plataformas e práticas de trabalho são os sistemas que vinculam a intenção à ação de forma automatizada e integrada. Os serviços de aplicativos precisam fazer parte dessa cadeia, e isso representa uma mudança mais fundamental do que simplesmente uma alteração nos tempos de execução.

Às vezes, os serviços precisam ser injetados em componentes existentes – como a visibilidade e o controle excepcionais que o Aspen Mesh adiciona ao Istio . Como alternativa, ferramentas de conexão como o F5 Container Connector podem vincular ambientes a serviços, para que, à medida que pods do Kubernetes são adicionados ou removidos, eles possam ser protegidos, dimensionados e observados.

O ideal é que o código para criar os serviços do aplicativo exista no mesmo repositório que o código desse aplicativo e seja implantado da mesma maneira. Definições de serviço de aplicativo – por exemplo, um serviço de firewall de aplicativo da web – precisam existir como código e ser tratadas como código, por meio do qual uma alteração e confirmação de definição de serviço no gerenciamento de código-fonte produz uma implantação de firewall de aplicativo da web de produção sem intervenção humana adicional. Em notícias de última hora, a falante Melaine Cebula , do Airbnb, descreveu exatamente esse modelo em sua palestra principal na quarta-feira na Kubecon, quando descreveu manter todos os componentes de um serviço – incluindo definições de infraestrutura em um único projeto (assim como cerca de cinquenta outras coisas legais que eles fazem para facilitar a vida dos desenvolvedores de aplicativos).

Essa mudança na instanciação do serviço (juntamente com a bem-vinda morte das longas filas de tickets de TI) é drástica e óbvia.

A segunda mudança talvez seja um pouco mais mundana, mas ainda assim crítica. Uma das vantagens do Kubernetes e dos contêineres é a portabilidade entre ambientes. Seu microsserviço gerenciado pelo Kubernetes será executado em qualquer lugar que um mecanismo de contêiner compatível o faça (dica: em qualquer lugar), e os mesmos serviços de aplicativo também devem estar lá, não "mais ou menos iguais" ou "fazem a mesma coisa de uma maneira diferente com uma interface ligeiramente diferente". O mesmo. Isso significa que o número de lugares onde precisamos nos posicionar está crescendo o tempo todo.

A necessidade de trabalhar da mesma maneira e nos mesmos lugares que todas as suas implantações atuais e potenciais do Kubernetes se tornou um princípio orientador para o F5.

É absolutamente crítico, pois nossos clientes não apenas confiam em nós para manter não apenas seus aplicativos existentes dimensionados e seguros, mas também precisam saber que protegeremos e observaremos os aplicativos que estão — até o momento em que este artigo foi escrito — sendo considerados como uma molécula de cafeína desonesta que se liga a um receptor de adenosina sortudo que precisa de um reforço pós-almoço.