A ironia é deliciosa com a palavra da moda do dia: nativo da nuvem.
A primeira coisa a ser observada é que o nativo da nuvem, apesar do nome, não requer nuvem. Eu sei direito? O nome vem da abordagem arquitetônica de construção de um aplicativo que depende de infraestrutura e é projetado em torno dos conceitos de nuvem: elasticidade, economia de escala e computação distribuída. É indiscutivelmente a computação em nuvem que impulsionou esses conceitos em todos os aspectos da entrega de aplicativos : da arquitetura do aplicativo à automação, da integração baseada em API à infraestrutura. A computação em nuvem mudou a maneira como desenvolvemos, construímos e implantamos aplicativos. Os aplicativos que nasceram na nuvem pública naturalmente assumiram muitas das mesmas dependências e características. Assim, o nome representa com precisão a etimologia do estilo arquitetônico.
Também há, sem dúvida, uma ligação entre a nuvem nativa e os contêineres. Isso por si só o torna diferente de aplicativos criados na nuvem, que dependem principalmente de máquinas virtuais e serviços nativos da nuvem para atingir objetivos semelhantes. Nuvem nativa e contêineres são fortemente acoplados porque os orquestradores de contêineres associados (Kubernetes) são os meios mais fáceis e predominantes de acoplar aplicativos com a infraestrutura necessária para fornecer elasticidade e, por meio dela, a economia de escala desejada.
Em um aplicativo nativo da nuvem, os componentes são atomizados para oferecer suporte à economia de escala. Daí a razão pela qual nuvem nativa e contêineres são quase sinônimos. Você precisa ser capaz de dimensionar apenas as funções que estão em demanda, sob demanda. Esse tipo de particionamento elástico e funcional de aplicativos tem sido tradicionalmente obtido por meio de arquiteturas que dependem do roteamento da camada 7 (HTTP), e a nuvem nativa não é exceção. Os mesmos princípios se aplicam a esses aplicativos modernos e geralmente fazem uso de um controlador de entrada (um serviço de aplicativo de infraestrutura) que gerencia a distribuição de solicitações de entrada para a instância apropriada baseada em contêiner de um componente de aplicativo.
Esse particionamento geralmente é realizado no nível da API, onde os URIs são correspondidos às chamadas de API que são correspondidas aos serviços de contêiner específicos. O controle de entrada direciona solicitações para o serviço de contêiner apropriado e este, por sua vez, distribui solicitações entre um pool de instâncias de componente/aplicativo. Este é um bolo de duas camadas com controle de entrada da camada 7 (HTTP) distribuindo para um balanceador de carga simples (POLB) para entrega e atendimento.
Além disso, temos a dependência de registros de serviço que, nos bastidores, é outro serviço de aplicativo de infraestrutura necessário para facilitar a elasticidade de aplicativos nativos da nuvem. Sem um mecanismo de descoberta de serviço, o balanceamento de carga e o controle de entrada não funcionam, o que torna o aplicativo inoperante.
Esse relacionamento — entre componentes, serviços, registros de serviços, balanceadores de carga e controle de entrada — é a encarnação dos princípios dos aplicativos nativos da nuvem. Os componentes e a infraestrutura do aplicativo estão intimamente vinculados, mas sem serem fortemente acoplados. Os componentes não conseguem atingir a economia de escala ou distribuição entre ambientes sem o roteamento da camada 7 e os recursos tradicionais de balanceamento de carga. A dependência entre infraestrutura e aplicativos é real e crítica para o imperativo comercial de entregar aplicativos.
Nada disso depende ou requer qualquer tipo de ambiente de computação em nuvem. Um aplicativo nativo da nuvem pode ser - e geralmente é - implantado sozinho. Na verdade, se olharmos para os dados sobre contêineres e onde eles estão sendo executados, descobriremos que "on-premises" mantém sua ascendência sobre os ambientes de nuvem pública.
Agora, embora seja certamente verdade que é possível implantar contêineres em uma nuvem privada (local) - e de fato nossa própria pesquisa continua mostrando que a nuvem privada local continua sendo o modelo de nuvem mais popular em uso. Mais de três quartos (79%) dos entrevistados em nosso State of Application Services 2019 têm aplicativos em uma nuvem privada local, enquanto a nuvem pública continua lutando para atingir a maioria em 45%.
Os aplicativos nativos da nuvem são uma arquitetura de rápido crescimento que você pode ter certeza de que continuará a crescer nos próximos cinco anos. Entender a relação e a dependência deles com os serviços de aplicativos de infraestrutura é um componente essencial para entregar (e proteger) com sucesso esses aplicativos modernos.