Aplicativos nativos da nuvem não exigem uma nuvem

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

A ironia é deliciosa com a palavra da moda do momento: nativo da nuvem.

A primeira coisa a observar é que uma aplicação nativa da nuvem, apesar do nome, não requer a nuvem. Pois é! O nome vem da abordagem arquitetônica de criar uma aplicação que depende de infraestrutura e é projetada com base nos conceitos de nuvem: elasticidade, economia de escala e computação distribuída. É inegável que a computação em nuvem levou esses conceitos a todos os aspectos da entrega de aplicações: da arquitetura de aplicações à automação, da integração baseada em APIs à infraestrutura. A computação em nuvem mudou a forma como desenvolvemos, criamos e implantamos aplicações. As aplicações que nasceram na nuvem pública naturalmente incorporaram muitas das mesmas dependências e características. Assim, o nome representa com precisão a etimologia desse estilo arquitetônico.

Também é inegável que existe uma relação entre aplicações nativas da nuvem e contêineres. Isso, por si só, as diferencia das aplicações criadas na nuvem, que dependem principalmente de máquinas virtuais e serviços nativos da nuvem para alcançar objetivos semelhantes. Aplicações nativas da nuvem e contêineres estão intimamente ligados porque os orquestradores de contêineres associados (Kubernetes) são a maneira mais fácil e predominante de integrar as aplicações à infraestrutura necessária para proporcionar elasticidade e, por meio dela, a economia de escala desejada.

Em uma aplicação nativa da nuvem, os componentes são divididos em unidades menores para viabilizar a economia de escala. Por isso, aplicações nativas da nuvem e contêineres são conceitos praticamente sinônimos. É necessário poder escalar, sob demanda, apenas as funções que estiverem sendo requisitadas. Tradicionalmente, esse tipo de particionamento funcional e elástico das aplicações tem sido implementado por meio de arquiteturas baseadas em roteamento de camada 7 (HTTP), e as aplicações nativas da nuvem não são exceção. Os mesmos princípios se aplicam a essas aplicações modernas, que geralmente utilizam um controlador de ingresso (um serviço de infraestrutura da aplicação) para gerenciar a distribuição das solicitações recebidas à instância apropriada, baseada em contêiner, de um componente da aplicação.

Esse particionamento geralmente é realizado no nível da API, em que os URIs são associados a chamadas de API que, por sua vez, são vinculadas a Serviços específicos de contêineres. O controle de entrada direciona as solicitações ao Serviço de contêiner apropriado que, por sua vez, distribui as solicitações entre um conjunto de instâncias do componente/aplicativo. Trata-se de uma arquitetura de duas camadas, na qual o controle de entrada da camada 7 (HTTP) distribui as solicitações para um balanceador de carga convencional (POLB), responsável pela entrega e pelo atendimento.

Além disso, há a dependência de registros de serviços que, nos bastidores, constituem outro serviço de aplicação de infraestrutura necessário para viabilizar a elasticidade das aplicações nativas da nuvem. Sem um mecanismo de descoberta de serviços, o balanceamento de carga e o controle de entrada deixam de funcionar, o que, por sua vez, torna a aplicação inoperante.

Essa relação — entre componentes, serviços, registros de serviços, balanceadores de carga e controle de entrada — é a materialização dos princípios das aplicações nativas da nuvem. Os componentes da aplicação e a infraestrutura estão intimamente ligados, sem que haja um acoplamento rígido entre eles. Os componentes não conseguem obter economia de escala nem ser distribuídos entre diferentes ambientes sem os recursos de roteamento da camada 7 e do tradicional balanceamento de carga. A dependência entre a infraestrutura e as aplicações é real e essencial para atender à necessidade estratégica da empresa de disponibilizar aplicações.

Nada disso depende nem exige qualquer tipo de ambiente de computação em nuvem. Uma aplicação nativa da nuvem pode ser — e muitas vezes é — implantada de forma independente. Na verdade, ao analisarmos os dados sobre contêineres e onde eles estão sendo executados, constatamos que os ambientes "locais" continuam predominando sobre os ambientes de nuvem pública.

Embora seja verdade que é possível implantar contêineres em uma nuvem privada (local) — e, de fato, nossas próprias pesquisas continuam mostrando que a nuvem privada local ainda é o modelo de nuvem mais utilizado. Mais de três quartos (79%) dos participantes da nossa pesquisa State of Application Services 2019 têm aplicações em uma nuvem privada local, enquanto a nuvem pública ainda não consegue alcançar a maioria, ficando em 45%.

As aplicações nativas da nuvem são uma arquitetura em rápida expansão, que certamente continuará crescendo nos próximos cinco anos. Compreender sua relação com os serviços de aplicação da infraestrutura — e sua dependência deles — é fundamental para disponibilizar (e proteger) essas aplicações modernas com sucesso.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie