Aplicações Cloud Native

Sete princípios para arquitetura Cloud Native em Kubernetes

Hoje em dia é possível containerizar quase qualquer aplicação e colocá-la pra rodar. Porém, criar aplicações Cloud Native exigem um esforço extra.

Aplicações “Cloud Native” antecipam a falha. Elas rodam e escalam mesmo sob falhas de infraestrutura, mas para oferecer essas capacidades, plataformas como Kubernetes impõem algumas restrições para garantir o melhor aproveitamento e sucesso da aplicação.

Boas práticas no design de software são de suma importância para seu sucesso, escolha o seu, mas seja rápido :D

KISS — Keep it simple, stupid
DRY — Don’t repeat yourself
YAGNI — You aren’t gonna need it
SoC — Separation of concerns

Esses princípios não são regras, mas representam a sabedoria comum de muitos desenvolvedores e podem lhe poupar uma longa caminhada.

Inspirados por este artigo do @bibryam e pela Red Hat, apresentamos os 7 princípios para arquitetura “Cloud Native” em Kubernetes.1-Responsabilidade Única

Este princípio tem muita inspiração no mote Unix que diz “Do one thing, and do it well.” Pensando nisso, cada contêiner deve ter uma responsabilidade específica, principalmente pela abordagem de “POD” do kubernetes, em que diversos containers podem estar juntos em um “POD”, cada um desempenhando uma função, por exemplo o Prometheus e o auth-proxy, onde cada container faz apenas uma tarefa: o proxy autentica o usuário e então redireciona a requisição para o prometheus, a aplicação propriamente dita.2-High Observability

Containers provêem uma forma muito simples de empacotar e rodar aplicações, porém saber exatamente o que acontece com a “saúde” de seu container e conseguir agir conforme cada evento é um pré-requisito fundamental para atingir o máximo de automação, eficiência e resiliência.

De forma prática, seu container deve exportar logs, tracing das requisições e também ter formas de checagem de saúde com os famosos “probes”, que devem ser pensados já no desenvolvimento da aplicação, permitindo saber como sua aplicação está se comportando a cada checagem.

Com o avanço do DevOps, as responsabilidades têm sido cada vez mais compartilhadas dentro das equipes, porém se quem desenvolve a aplicação já pensar também em como ela será monitorada, deixará esse teste pronto para o orquestrador.

3-Ciclo de vida

Bem simples, como o nome já sugere. Sua aplicação deve estar preparada para receber sinais da plataforma para terminar, e principalmente deve obedecê-los, pois caso contrário ele pode ser seguido por um sinal de “KILL”, o que pode causar comportamentos inesperados.

Confuso? então um exemplo: uma aplicação de banco de dados não deve ser terminada “a força” e sim de forma “graciosa” — a diferença de “SIGKILL" x "SIGTERM” — o kill irá interromper a atividade e com risco de causar danos irreparáveis em seus dados.

4-Imutabilidade

Essa propriedade geralmente é ignorada ou tem sua importância subestimada, mas garantir a integridade da aplicação em diversos ambientes não é uma tarefa simples, embora importante, principalmente com uma equipe grande ou com diversos níveis de conhecimento.

A imutabilidade lhe permitirá “promover” a imagem de sua aplicação entre os diferentes ambientes, dando a certeza de que seu comportamento será mantido. Essa propriedade está muito ligada aos princípios de externar dependências e configurações, como variáveis de ambiente, tratadas em 12Factor, que eu indico muito a leitura!5-Processos descartáveis

Um dos motivos de se mover para containers está em sua natureza volátil e na possibilidade de ser rapidamente substituído por outro container, a qualquer tempo ou motivo. Isso pode acontecer por diversos motivos, como falta de recursos, falha na aplicação, comportamento de scale-up / scale-down.

Para isso, a aplicação precisa manter seu estado externamente, tornando-a rápida para iniciar e receber conexões.

Outra boa prática é construir containers pequenos, pois uma grande imagem leva mais tempo para ser transferida, mesmo dentro de um cluster, o que também pode interferir no processo de resiliência de sua aplicação, isso sem falar no throughput de rede :D

6-Auto-contido

Este princípio indica que o container deve possuir, após o processo de build, tudo que é necessário para a aplicação rodar, deixando de fora apenas configurações, que podem variar entre ambientes como já falamos acima. Exemplo: adicionar no start da aplicação o download de alguma biblioteca ou outra dependência externa. Não só estamos adicionando tempo no processo, como também correndo o risco dele não funcionar, impactando principalmente no momento de autoscale, o qual espera-se que seja quase instantâneo.

7-Confinamento de Start

A aplicação deve ter fronteiras bem demarcadas, pois um container não é apenas um processo, ele depende principalmente de CPU, memória e de seu espaço em disco.

Sendo assim, ele deve declarar isso à plataforma e a aplicação deve obedecer essas declarações a fim de não causar falhas ao tentar ultrapassar seus recursos. Caso a linguagem utilizada permita, declare os recursos que serão utilizados para que ela não tenha comportamentos incorretos ao tentar utilizar recursos que não receberá.

Conclusão:“Cloud Native não é um estado, mas uma jornada!”Dicas Finais:

Sempre busque criar imagens de containers menores. Saiba mais.
Não dê privilégios ou permissões desnecessárias. Saiba mais.
Exponha as portas específicas de sua aplicação.
Stateless é o ideal, mas se não tiver jeito, use volumes para persistência de dados, object storage pode ser uma ótima opção.
Use tags e metadata em suas imagens e onde mais você puder!
Participe de um grupo e discuta idéias, se estiver em SP -> https://www.meetup.com/Cloud-Native-Sao-Paulo/

Fontes:Slideshare, Docker, ProjectAtomic, Openshift, UseNix, LeanPub, 12Factor e RedHat