Um guia para iniciantes no desenvolvimento de aplicativos nativos em nuvem

Princípios da arquitetura nativa da nuvem

Antes de mergulhar no desenvolvimento, vamos analisar alguns dos princípios de arquitetura mais comuns nos quais as organizações nativas da nuvem confiam.

Conteinerização

Mais frequentemente associada ao Docker, a conteinerização é uma forma de virtualização em que os aplicativos são configurados para rodar em ambientes isolados, chamados containers, enquanto ainda utilizam o kernel do sistema operacional host. Os contêineres são muito mais leves do que a virtualização tradicional. Eles dependem do sistema operacional host para fazer grande parte do trabalho pesado, em vez de um hipervisor ou outra camada de máquinas virtuais (VM).

A vantagem da conteinerização em um ambiente nativo da nuvem é que os contêineres são leves, portáteis e —o mais importante— repetíveis. Isso permite que os desenvolvedores escrevam, testem e implantem aplicativos em ambientes consistentes, minimizando custos.

Automação

Organizações nativas da nuvem usam a automação para reduzir erros humanos, tornar processos repetíveis mais eficientes e assumir um controle preciso sobre sua infraestrutura de aplicativos.

Embora seja possível construir, testar, implantar e gerenciar manualmente a infraestrutura de seus aplicativos, os provedores de nuvem oferecem ferramentas para abstrair muitos desses processos manuais. Isso permite que organizações nativas da nuvem sejam mais eficientes em tudo, desde a contratação até as necessidades de infraestrutura.

Orquestração

Embora a conteinerização possa reduzir custos ao empacotar serviços leves, extrair o máximo deles em um ambiente de produção requer uma estratégia chamada orquestração. Em resumo, orquestração é o processo de automatizar o gerenciamento do ciclo de vida de todos os contêineres em um ambiente de produção para gerenciar com eficiência tarefas como criação e destruição de contêineres, escalonamento horizontal, controle de versão e gerenciamento de rede e dependências.

O Kubernetes é uma das ferramentas mais populares para orquestração de contêineres; no entanto, existem alternativas. O Docker Compose, mais leve, por exemplo, é frequentemente usado para orquestração local. No entanto, independentemente da ferramenta, o gerenciamento bem-sucedido dos recursos de produção quase sempre requer algum tipo de orquestração.

Microsserviços

Quando combinados, os conceitos de conteinerização e automação se prestam bem a um padrão de arquitetura conhecido como arquitetura de microsserviços. Esse padrão é definido pela presença de aplicativos complexos compostos por muitos serviços pequenos e independentes, que podem ser escalonados e alterados de forma independente.

Uma arquitetura de microsserviços é comum em ambientes nativos de nuvem, pois a natureza inerente da orquestração e da conteinerização se presta bem a esse padrão. Isso contrasta fortemente com arquiteturas monolíticas, que são mais fortemente acopladas e, consequentemente, exigem mais recursos e são mais difíceis de escalar da mesma forma.

Malha de serviço

Em um ambiente nativo de nuvem, a malha de serviços é a cola que mantém todos os serviços distintos unidos. À medida que os aplicativos escalam, especialmente em uma arquitetura de microsserviços, monitorar e gerenciar os diferentes componentes pode ser particularmente desafiador. A malha de serviços cria uma camada de rede dedicada que permite uma comunicação mais simples e observável entre os serviços. Geralmente, ela oferece suporte a diversos recursos, incluindo balanceamento de carga, criptografia e recuperação de desastres.

Padrões nativos da nuvem e melhores práticas

Embora as ferramentas e os padrões arquitetônicos de um ambiente nativo da nuvem sejam importantes, utilizá-los de forma eficaz exige a observância de práticas recomendadas e padrões comumente aceitos. Muitas dessas práticas se enquadram no DevOps, uma abordagem de desenvolvimento de software que enfatiza a melhoria contínua, a automação, a colaboração e a propriedade compartilhada para aprimorar a velocidade, a qualidade e a confiabilidade dos produtos resultantes.

Integração contínua

Uma das principais vantagens de uma estratégia de desenvolvimento de aplicativos nativos em nuvem é o incentivo para lançar alterações com antecedência e frequência. Devido às ferramentas e outras automações inerentemente disponíveis no ambiente típico de nuvem, a prática de integração contínua (CI) é particularmente valiosa, pois permite que os desenvolvedores testem e lancem seu código com frequência.

A CI adiciona um ciclo de feedback mais preciso, no qual as alterações no código são criadas, empacotadas e testadas automaticamente, seguindo os princípios do Agile. Isso permite a detecção de problemas mais precoce e confiável, já que a infraestrutura subjacente e seu gerenciamento garantem que todas as alterações sejam executadas da mesma forma e na mesma infraestrutura.

Imagem mostra como a integração contínua e a entrega contínua se encaixam.

Imutabilidade

O que torna a infraestrutura nativa da nuvem tão previsível é sua imutabilidade inerente. Imutabilidade significa que a infraestrutura em si não pode ser alterada após a implantação. Por exemplo, na conteinerização, isso significa que, uma vez construído, um contêiner não muda ao longo do tempo. Seu arquivo de definição gerencia sua configuração, o orquestrador gerencia seu ciclo de vida e a malha de serviços conecta quaisquer dependências.

Em vez de uma infraestrutura mutável, como serviços bare-metal gerenciados manualmente, a imutabilidade da infraestrutura nativa da nuvem garante maior confiabilidade. Em caso de falha inesperada, recursos imutáveis ​​podem ser recriados de forma idêntica, o que pode reduzir o tempo de inatividade. Isso também ajuda a aumentar a segurança. Reduzir o potencial de alterações de configuração significa que o controle de versão gerencia os recursos. Cada versão lançada não só é diferente das demais, como também pode ser verificada programaticamente.

Infraestrutura como código

A infraestrutura como código (IaC) está no centro de uma estratégia nativa em nuvem bem definida. Em vez de usar ferramentas de configuração físicas ou interativas, a IaC se baseia em práticas padrão de desenvolvimento de software e permite o gerenciamento e o provisionamento da infraestrutura usando arquivos legíveis por máquina.

Isso permite que as equipes de TI gerenciem a infraestrutura subjacente do aplicativo da mesma forma que gerenciam todos os outros arquivos de código-fonte. Conceitos como controle de versão, reprodutibilidade, automação e testes de ponta a ponta podem ser aplicados aos recursos nos quais o software do aplicativo é executado, além do próprio software.

Sem servidor

Levados ao extremo, conteinerização, orquestração e microsserviços podem ser abstraídos por um conceito conhecido como computação sem servidor. Embora o próprio nome implique que não há servidores, a realidade da computação sem servidor é que os servidores são completamente abstraídos.

Em vez de contêineres de longa execução, a computação sem servidor se caracteriza por sua natureza orientada a eventos e sem estado. Embora possa ser uma transição desafiadora para métodos de computação sem servidor, a computação sem servidor permite que desenvolvedores nativos da nuvem se concentrem quase exclusivamente no código, em vez da infraestrutura. Quando implementada corretamente, isso pode ajudar a reduzir custos, garantindo que apenas os recursos utilizados sejam cobrados.

GitOps

A grande maioria dos aplicativos nativos da nuvem é gerenciada usando uma abordagem de desenvolvimento de software conhecida como GitOps. Como o nome sugere, GitOps é uma metodologia inspirada em DevOps que utiliza um sistema de controle de versão —normalmente o Git— como fonte de verdade durante todo o ciclo de vida de um aplicativo, do desenvolvimento à infraestrutura.

O GitOps utiliza as melhores práticas de desenvolvimento de software incorporadas ao ecossistema Git para implementar a revisão e a validação de arquivos IaC. Isso incentiva o uso de infraestrutura imutável, utiliza ferramentas de automação existentes e ajuda a manter uma gestão de mudanças eficaz.

É uma maneira eficaz de entender não apenas o que está acontecendo na infraestrutura nativa da nuvem de um aplicativo, mas também como e por quê. Além disso, cria um histórico de alterações bem versionado, o que permite maior resiliência, eliminando o risco de qualquer alteração isolada. Na maioria das organizações nativas da nuvem, o GitOps é o principal impulsionador da evolução e da inovação.

Metodologias de desenvolvimento nativas da nuvem

Existem alguns fatores da metodologia de aplicativo de 12 fatores —uma referência para desenvolvedores de aplicativos— que são fundamentais para o desenvolvimento de aplicativos nativos na nuvem, que são detalhados nesse link.

Construir, lançar, executar

A abordagem de construção, lançamento e execução separa cada estágio do desenvolvimento e implantação de aplicativos nativos da nuvem:

1. Construção. A base de código de um aplicativo passa pelo estado de construção, onde é transformada de código-fonte bruto em um pacote executável conhecido como construção.
2. Lançamento. A compilação é então combinada com quaisquer valores de configuração necessários para a execução no ambiente de destino. Isso é conhecido como lançamento.
3. Executar. O executável de lançamento é executado no ambiente de desempenho desejado.

Esse fluxo de trabalho bem definido costuma ser associado a uma ferramenta de implantação e integração contínua (CI), como Jenkins ou Capistrano, que permite executar testes automatizados, reverter para compilações anteriores e muito mais. Se algo der errado, os desenvolvedores podem executar novamente uma versão pré-compilada em um ambiente ou infraestrutura diferente sem precisar reimplantar todo o aplicativo.

Processos

Na computação em nuvem, processos desacoplados e sem estado são muito mais escaláveis ​​e gerenciáveis ​​do que os com estado. Embora possa parecer contraintuitivo desenvolver um processo sem estado, isso enfatiza a dependência de serviços de suporte com estado que permitem que os processos sem estado sejam ampliados ou reduzidos —ou reinicializados completamente— com risco mínimo para a qualidade da aplicação.

Embora seja possível executar processos nativos da nuvem de diversas maneiras, alguns ambientes específicos, como o Heroku, oferecem seus próprios tempos de execução baseados em valores de configuração fornecidos pelo desenvolvedor. Isso geralmente é feito por meio de uma tecnologia de conteinerização, como Docker ou Kubernetes. Contêineres são uma excelente maneira de encapsular o único processo necessário para executar um determinado aplicativo e incentivar o uso de aplicativos sem estado.

Concorrência

Os aplicativos nativos da nuvem são programados para serem escaláveis ​​horizontalmente. Esses aplicativos isolam serviços em processos individuais sem estado que podem lidar com cargas de trabalho específicas simultaneamente. Os processos são escaláveis ​​de forma eficiente quando não têm estado e desconhecem os outros processos independentes.

A simultaneidade é um ótimo exemplo de por que muitos aplicativos nativos da nuvem se inclinam para arquiteturas orientadas a serviços. Aplicativos monolíticos só podem ser escalados verticalmente até certo ponto. Cada componente pode ser escalado com mais eficiência para lidar com uma carga quando um desenvolvedor divide um aplicativo monolítico em vários processos específicos. Uma série de ferramentas está disponível para automatizar o gerenciamento e o escalonamento desses processos, incluindo o Kubernetes e outros serviços proprietários de provedores de serviços de nuvem.

Descartabilidade

Vários provedores de nuvem oferecem infraestruturas mais voláteis a um custo reduzido. Isso promove uma escalabilidade mais barata, mas traz o risco de descarte repentino de processos. Embora nem sempre seja o caso, aplicativos nativos da nuvem projetados para descarte enfatizam a importância de aplicativos autorreparáveis.

Planeje falhas inesperadas para permitir procedimentos de desligamento mais suaves e armazenar quaisquer dados com estado fora do isolamento do processo. No entanto, é mais fácil projetar um sistema autorreparável usando ferramentas de orquestração, como o Kubernetes, e back-ends de enfileiramento abrangentes, como o Amazon Simple Queue Service ou o RabbitMQ.

Sobre o autor: Zachary Flower, um desenvolvedor web freelancer, escritor e polímata, se esforça para criar produtos tendo em mente os objetivos do usuário final e do negócio, além de priorizar a simplicidade e a usabilidade.