Para aproveitar totalmente a arquitetura nativa da nuvem, vamos entender o que realmente significa ser cloud native.
Há algum tempo, foi introduzida uma tecnologia que prometia mudar radicalmente a forma como as empresas funcionavam. No início, era usado apenas por pessoas que compraram a visão e estavam dispostas a aceitar interrupções e complicações para fazer parte do futuro.
Apesar das promessas loucas de aumento de produtividade desses primeiros adeptos, a maioria das pessoas estava hesitante e continuou fazendo as coisas do jeito que sempre fizeram. Mas lentamente, à medida que a tecnologia se tornava cada vez mais confiável, o equilíbrio mudou.
O custo da antiga forma de negócio estava crescendo, era mais difícil encontrar trabalhadores qualificados para dar suporte às tecnologias mais antigas, e as empresas que adotaram a tecnologia mais nova eram mais ágeis e capazes de continuar inovando.
Isso soa como a história da computação em nuvem e a adoção de software cloud native, mas na verdade é de mais de um século antes.
Como Tim Hartford explicou em “50 coisas que fizeram a economia moderna”, levou mais de 50 anos para as empresas começarem a construir seus negócios em torno da eletricidade fornecida por um fornecedor de energia central em vez de instalar seus próprios equipamentos à base de vapor.
Assim como ter seu próprio data center, administrar sua própria usina de vapor era caro, mas parecia mais confiável quando a eletricidade era nova. No entanto, à medida que a tecnologia de eletricidade melhorou, não era mais econômico contar com vapor e os trabalhadores necessários para manter essa infraestrutura eram mais difíceis de encontrar.
Isso deve soar familiar para quem tenta contratar profissionais de TI qualificados.
As dificuldades do mercado
Assim como é difícil justificar a construção de sua própria usina, é difícil competir com a escala dos principais provedores de nuvem. Confiar em seus serviços significa que seu pessoal de operações pode se concentrar nos problemas que são exclusivos de sua empresa.
Não há vantagem competitiva em armazenar servidores individuais em rack, trocar discos rígidos ou verificar se há cabos Ethernet quebrados.
Depois de 100 anos, ninguém fala em ser “nativo elétrico”. Usar eletricidade é simplesmente como o trabalho é feito.
AWS Cloud Native
E 15 anos após o lançamento do primeiro serviço da AWS, a maioria das empresas iniciou sua migração para a nuvem ou está considerando seriamente como começar. E para muitas empresas, a migração para a nuvem começa com uma replicação do ambiente hospedado.
Isso costuma ser chamado de abordagem “lift and shift”, em que o software em alguns servidores é copiado em imagens de máquina e implantado como servidores virtuais em uma conta usando o EC2 da AWS, as máquinas virtuais do Azure ou o Compute Engine do Google.
Assim como os servidores de um data center são protegidos por firewall do mundo externo, as regras de rede são configuradas para garantir que apenas os servidores virtuais voltados para o cliente sejam acessíveis externamente.
Quando chegar a hora de atualizar seu software, você terá algum tempo de inatividade, pois o software em seu servidor virtual é desligado, atualizado e reiniciado.
Se sua experiência na nuvem parar por aqui, você se perguntará sobre o motivo de tanta confusão. Pode haver alguma economia de custos, e certamente é mais rápido ativar uma instância do EC2 do que solicitar e instalar um novo servidor físico, mas o trabalho real do dia a dia de seus desenvolvedores e equipes de operações não muda muito.
Isso ocorre porque você não adaptou suas ferramentas e processos para aproveitar o que a nuvem oferece. Resumindo, seu software ainda não é cloud native.
O que é Cloud Native?
Mas, o que é realmente “cloud native”? O que isso significa? A Cloud Native Computing Foundation, ou CNCF, foi criada como um desdobramento da Linux Foundation para “tornar a computação nativa em nuvem onipresente”.
Eles pastoreiam muitos dos projetos que permitem software nativo de nuvem multiplataforma e elaboraram uma definição do que significa:
As tecnologias nativas da nuvem capacitam as organizações a criar e executar aplicativos escaláveis em ambientes modernos e dinâmicos, como nuvens públicas, privadas e híbridas. Contêineres, malhas de serviço, microsserviços, infraestrutura imutável e APIs declarativas exemplificam essa abordagem.
Essas técnicas permitem sistemas fracamente acoplados que são resilientes, gerenciáveis e observáveis. Combinados com automação robusta, eles permitem que os engenheiros façam alterações de alto impacto com frequência e previsibilidade com o mínimo de trabalho.
Vamos passar pelas palavras mais importantes, dar uma olhada no que elas significam e, em seguida, percorrer as ferramentas das plataformas nativas da nuvem que nos permitem construir sistemas nativos da nuvem.
Cloud Native: 5 princípios
- Escalável
- Resiliente
- Gerenciável
- Observável
- Automatizado
1. Escalável
Vamos começar com escalável. A escalabilidade é um dos principais motivadores para migrar para a nuvem. Mas a maior desvantagem de executar seu próprio data center é que leva muito tempo para adquirir e configurar um novo hardware.
Isso significa que você precisa reservar servidores com base em uma estimativa de quanta capacidade será necessária no dia mais movimentado. Se a sua empresa tem uma temporada movimentada, você tem excesso de capacidade na maior parte do ano. Pior ainda, se você subestimar a demanda, seu sistema não funcionará quando você mais precisar.
Tornar seus serviços escaláveis provavelmente exigirá que seus desenvolvedores façam alterações em seus softwares. Isso pode ser complicado, porque geralmente significa repensar como seus aplicativos são arquitetados. No entanto, a recompensa vale a pena.
A primeira etapa é dividir um aplicativo monolítico em microsserviços. Embora você possa executar um monólito na nuvem, não pode aumentar os recursos para uma única parte de um monólito; é tudo ou nada.
Além disso, com os microsserviços, você pode dimensionar diferentes áreas funcionais do seu aplicativo em taxas diferentes, dependendo do que elas precisam.
Depois de pensar em termos de microsserviços, o próximo passo é pensar em colocar esses microsserviços em contêineres. O Docker popularizou a ideia de empacotar software em pacotes imutáveis e executá-los isoladamente, sem exigir um sistema operacional completo por serviço.
Essa diferença entre contêineres e máquinas virtuais permite que você execute muito mais contêineres no mesmo hardware subjacente do que com VMs.
O que torna um Microsserviço Cloud Native?
Não há nada sobre microsserviços ou contêineres que impeça você de implantá-los em um data center. Portanto, o problema é que você ainda precisa alocar e gerenciar os servidores subjacentes que os hospedam.
Um Microsserviço Cloud Native aproveita os serviços de um provedor de nuvem. Assim como a execução na nuvem significa que você não precisa mais se preocupar com o estado das placas de rede e dos ventiladores do seu servidor, uma arquitetura nativa da nuvem significa que você pode evitar se preocupar com a alocação de servidores virtuais.
Os Microsserviços Cloud Native seguem determinados princípios de design. O mais importante é que eles são projetados como uma infraestrutura imutável.
Isso significa duas coisas:
- O contêiner que hospeda seu microsserviço não armazena dados.
- Depois de iniciar um contêiner, você não o modifica.
Isso leva à pergunta: como você faz atualizações? A resposta é que em uma Arquitetura Cloud Native, sempre que você quiser alterar um microsserviço nativo da nuvem, você inicia uma nova instância com as atualizações e desativa a instância antiga.
Isso contrasta com a abordagem mais antiga de fazer atualizações em um único servidor.
Construindo Arquitetura Cloud Native
Depois de criar essas instâncias imutáveis, você estará no caminho certo para criar uma Arquitetura Cloud Native.
Suas equipes agora podem aproveitar os serviços de provedores de nuvem para aumentar a escalabilidade de seus sistemas. Ou seja, quando nenhuma instância de servidor é especial, você pode usar serviços do provedor de nuvem para dimensionar automaticamente ou configurar seu ambiente para adicionar e remover automaticamente instâncias de servidor virtual à medida que a carga em seu sistema muda.
Dividir seus serviços em componentes menores pode levar a mais benefícios de escalabilidade. Em alguns casos, você pode reduzir ainda mais um microsserviço nativo da nuvem, para apenas uma única função.
A AWS os chama de Lambdas, o Google de Cloud Functions e o Azure simplesmente de Functions. Eles são ainda mais simples de empacotar do que um contêiner, geralmente apenas um arquivo zip contendo algum código. Sua equipe de operações precisa apenas configurar o número máximo de funções a serem executadas simultaneamente e quanta memória fornecer a cada uma.
O provedor de nuvem se encarrega de alocar as máquinas subjacentes, dimensionando-as para cima e para baixo (e até mesmo desativando-as) automaticamente. Para processos ou serviços infrequentes que têm rajadas de solicitações, por exemplo, essas funções geralmente são muito mais econômicas do que um contêiner que é executado o tempo todo.
Funcionalidade de Dimensionamento com Arquitetura Cloud Native
As vantagens das Arquiteturas Nativas da nuvem vão muito além da capacidade de dimensionar a lógica de negócios do seu aplicativo.
E quando você tem uma infraestrutura imutável e sem estado, seus dados ainda precisam estar em algum lugar. Embora você possa executar bancos de dados de terceiros em servidores virtuais, uma arquitetura nativa de nuvem usa bancos de dados hospedados pelos próprios provedores de nuvem.
MySQL, Postgres e Oracle estão disponíveis em todos os três maiores provedores de nuvem, mas apenas o Azure possui uma versão hospedada do Microsoft SQL Server. Como os bancos de dados hospedados são gerenciados pelo seu provedor de nuvem, é fácil alocar recursos adicionais conforme necessário, como disco, memória e CPU, dimensionando ao longo do tempo conforme suas necessidades mudam.
Outras maneiras…
Você também pode começar a procurar outras maneiras não relacionais de armazenar seus dados. Um dos primeiros serviços da AWS foi o S3.
Ele permite que você coloque arquivos em “buckets” (Azure chama sua versão desse serviço de Blob Storage e o Google o chama de Cloud Storage). Existem bancos de dados de documentos, noSQL, bancos de dados de gráficos, data warehouses e até blockchains privados. Em outras palavras, ter esses armazenamentos de dados alternativos disponíveis apenas com uma API é poderoso.
Suas equipes são capazes de descobrir se existem soluções melhores de maneira muito mais rápida e barata do que em um ambiente auto gerenciado.
À medida que suas equipes se sentirem mais à vontade, elas explorarão mais maneiras de se concentrar nas principais competências da sua empresa. Por exemplo, considere a identidade do cliente. Em vez de gerenciar essas informações por conta própria, os provedores de nuvem (assim como empresas terceirizadas) têm soluções de gerenciamento de identidade usando padrões como OAuth2 e OIDC.
Existem soluções semelhantes, como aprendizado de máquina ou processamento em lote. As arquiteturas nativas da nuvem não apenas dimensionam seu software, mas também dimensionam os recursos de sua equipe, permitindo que você se concentre no que faz de melhor.
2. Resiliente
Outra parte importante de uma arquitetura nativa da nuvem é que ela é resiliente. O que isto significa? Como Matthew Titmus explica em “Cloud Native Go”:
“Resiliência (aproximadamente sinônimo de tolerância a falhas) é uma medida de quão bem um sistema resiste e se recupera de erros e falhas. Um sistema pode ser considerado resiliente se puder continuar operando corretamente—possivelmente em um nível reduzido—em vez de falhar completamente quando alguma parte do sistema falhar.”
Assim como você precisa modificar seu software para torná-lo mais escalável, você precisará fazer alterações para torná-lo mais resiliente. Assim como a escalabilidade, há recompensas tremendas quando você torna seus sistemas mais resilientes, porque eles continuam funcionando e as equipes não estão se esforçando para corrigir problemas.
Recursos disponíveis
Existem muitos recursos que discutem técnicas que tornam os serviços mais resilientes. (Se estão escrevendo software nativo da nuvem em Go, sem surpresa, uma leitura obrigatória.)
Esses padrões se concentram em como os dados fluem pelos seus serviços. Para dados que chegam a um serviço, você precisa limitar a quantidade de dados ao que pode ser processado em um tempo razoável.
Se entrar muito, a carga precisa ser descartada para responder às solicitações restantes em um período de tempo razoável. Quando seu serviço está solicitando dados de outro serviço, ele deve ser escrito para lidar com erros inevitáveis e os tempos limite que ocorrerão.
Os provedores de nuvem também fornecem algumas ferramentas para ajudar na resiliência. Há sobreposição com escalabilidade. Ou seja, se um microsserviço falhar devido a um erro raro, um autoescalador poderá iniciar uma nova cópia.
O escalonamento automático também permite que seus sistemas absorvam a carga em vez de eliminá-la. Ao usar bancos de dados ou plataformas de processamento de dados gerenciados, pode aumentar rapidamente seus recursos se precisarem de mais CPU ou armazenamento.
Os provedores de nuvem também permitem aumentar a resiliência espalhando seus serviços entre regiões. Uma região é uma área geográfica com um ou mais data centers, como a Costa Leste dos Estados Unidos ou São Paulo, Brasil. Dentro de uma região, cada data center é atribuído a uma das várias zonas de disponibilidade.
Para garantir que uma falha não cause uma interrupção, é recomendável iniciar serviços em várias zonas de disponibilidade. Seguir os princípios de apatridia e tratar seus servidores como gado significa que seu sistema continuará funcionando mesmo que uma única zona ou região de disponibilidade fique inativa.
Se usar um armazenamento de dados de um provedor de nuvem, ele poderá replicar dados automaticamente em zonas de disponibilidade e até mesmo regiões.
3. Gerenciável
Outro aspecto importante da computação nativa em nuvem é que ela é gerenciável.
Todos esses componentes podem ser visualizados a partir de uma interface do usuário ou ter seu status consultado por meio de uma API. Ter uma API para descobrir e modificar o estado do seu ambiente significa que você pode escrever ferramentas para esse trabalho de maneira repetível. Isso também significa que você pode descrever o ambiente em um script e executar esse script para implantar, atualizar ou excluir seus componentes. A AWS fornece uma ferramenta chamada CloudFormation para fazer isso.
4. Observável
Intimamente relacionado à capacidade de gerenciamento está a observabilidade. Depois de ter vários componentes em execução juntos, você deseja entender o que eles estão fazendo.
Você também quer saber quando algo dá errado. Mesmo que seus desenvolvedores projetem para resiliência, seu pessoal de operações ainda precisa saber sobre os problemas assim que eles acontecem para evitar que a situação piore. A Amazon fornece um serviço chamado CloudWatch para fornecer essa funcionalidade.
O CloudWatch coleta dados da AWS sobre como seu aplicativo está sendo executado e métricas sobre o desempenho de seus aplicativos. Além disso, os logs do seu aplicativo também podem ser enviados para o Cloudwatch, para que você veja as informações do seu código junto com as informações capturadas pela AWS.
(O Azure tem um serviço semelhante chamado Monitor, que possui um componente chamado Application Insights para capturar a telemetria do aplicativo, enquanto o Google fornece o Cloud Monitoring.)
Além de observar seus sistemas enquanto eles estão em execução, também é útil observar as chamadas de API para seu provedor de nuvem que configuram seu sistema. Essas chamadas podem informar se os sistemas estão configurados corretamente e podem detectar atividades maliciosas.
A AWS usa o CloudTrail para relatar chamadas de API, o Google possui logs de auditoria de nuvem, enquanto o serviço Monitor do Azure rastreia chamadas de API, bem como o desempenho do aplicativo.
5. Automatizável
Por fim, você precisa confiar na automação para garantir a consistência em seu ambiente de nuvem.
A automação une todos os nossos princípios nativos da nuvem. A escalabilidade é possível porque automatizamos a implantação de infraestrutura imutável. Os sistemas são mais resilientes quando podemos reiniciá-los automaticamente em caso de falha ou quando eles fazem failover automaticamente para um sistema de backup quando detectam um problema em uma dependência.
As ferramentas de gerenciamento automatizadas permitem que você acompanhe o que está sendo executado, e a automação permite que você descubra quando seus sistemas observáveis estão se comportando mal.
Há mais maneiras de a automação habilitar o software nativo da nuvem. Ao lançar novas versões, você não quer que um administrador do sistema instale o software manualmente. Em vez disso, você deve aproveitar os pipelines de implantação que automatizam o processo de compilação, teste e implantação, como o CodePipeline da AWS, o Cloud Build do Google ou os Pipelines do Azure.
A automação garante consistência e permite que você faça coisas como lançar uma nova versão do seu software para um subconjunto limitado de seus servidores para ver se funciona corretamente.
Além de melhorar a experiência de implantação de software nativo da nuvem, a automação também ajuda no gerenciamento do seu ambiente. Você precisa ter certeza de que todos os componentes do seu software estão configurados corretamente.
Isso inclui coisas como validar permissões de acesso, garantir que apenas aplicativos voltados para o cliente sejam expostos à Internet pública ou garantir que todos os seus recursos de nuvem estejam devidamente marcados com informações para identificar qual equipe é a proprietária.
Você também pode implementar medidas de otimização de custos na nuvem, como desligar componentes em um ambiente de controle de qualidade quando os engenheiros estiverem dormindo e ligá-los novamente quando voltarem ao trabalho.
Cloud Native vale a pena?
Como você viu, o objetivo de criar aplicativos nativos da nuvem não é estar atualizado com as últimas palavras da moda. Depois de seguir esses princípios e reprojetar seus aplicativos com uma arquitetura nativa da nuvem, sua empresa pode produzir um software mais confiável que atenda melhor às necessidades de suas equipes internas e de seus clientes.
Certamente, para empresas que investem em um data center e tecnologias mais antigas, isso não será fácil. Como Tim Hartford disse em seu artigo sobre a transição do vapor para a eletricidade e a adoção da tecnologia computacional:
“A coisa sobre uma tecnologia revolucionária é que ela muda tudo – é por isso que a chamamos de revolucionária. E mudar tudo leva tempo, imaginação e coragem – e às vezes muito trabalho duro.”
Assim como as empresas há 100 anos tiveram que fazer alterações em sua infraestrutura ao passar do vapor para a eletricidade, tornar-se cloud native significa que seus desenvolvedores e equipes de operações precisarão fazer alterações à medida que melhoram a escalabilidade, resiliência, capacidade de manutenção, observabilidade e automação de seu software e seu ambiente.
Requer a alteração de alguns padrões de desenvolvimento e a adoção de uma arquitetura nativa da nuvem usando as ferramentas dos provedores de nuvem. No entanto, as recompensas são notáveis. Bem-vindo ao futuro.
Quer continuar se aprofundando no assunto? Inscreva-se na nossa newsletter para receber em primeira mão conteúdos de tecnologia.
Autor: Jon Bodner, Senior Distinguished EngineerArtigo traduzido do portal CapitalOne. Leia a versão original em inglês.
