A computação em nuvem mudou a forma como criamos nossas aplicações. Elas já precisam nascer alinhadas com o novo ambiente para que possam usufruir de todos os recursos que a nuvem oferece. Desde a análise até a primeira linha de código, a aplicação deve estar preparada para não perder nenhuma dessas vantagens. Para isso, podemos seguir os 12 fatores de aplicações de nuvem que nos auxiliam a criar aplicações preparadas para ter acesso a todos os recursos da nuvem.
Uma das vantagens da nuvem é a alta disponibilidade. Sua aplicação precisa estar disponível a todo momento. Utilizando a arquitetura monolítica, isso se torna um pouco difícil, pois qualquer nova funcionalidade ou correção exige uma atualização e, para realizar essa atualização você precisa interromper momentaneamente a aplicação. E se houver atualizações diárias? Seu serviço será interrompido todos os dias mesmo que seja por um breve período de tempo? Isso se torna inviável já que hoje em dia um cliente pode acessar a qualquer hora e de qualquer lugar.
Claro que não estou dizendo que é a forma errada de desenvolver uma aplicação. Afinal, cada caso é um caso e além disso, ainda temos muitas aplicações monolíticas funcionando perfeitamente no mundo. Vantagens e desvantagens existem em qualquer abordagem.
Cada vez mais precisamos ter a ideia do conceito de aplicações desacopladas e uma forma de resolver o problema da atualização citada anteriormente é utilizar a arquitetura de microsserviços, pois podemos separar o monolítico em diversos microsserviços, cada um com uma responsabilidade. Podemos, por exemplo, ter um microsserviço para a autenticação e outros para cada módulo da aplicação com suas respectivas regras de negócios, assim podemos atualizar "pedaços" da aplicação e não a aplicação inteira de uma única vez.
As aplicações nativas de nuvem precisam, por natureza, devem ter baixo acoplamento, serem resilientes, gerenciáveis e observáveis. Agora vou detalhar os 12 fatores de aplicações de nuvem, criados pelo Heroku em 2012 e amplamente conhecidos, seguidos e respeitados até hoje.
12 fatores de aplicações de nuvem
-
Código fonte
O código fonte de uma aplicação precisa estar armazenado em um repositório de código fonte como o Git. Assim é possível ter o controle de versões do código e também a disponibilidade para realizar implantações em diferentes ambientes. Por exemplo, podemos ter códigos implantados no ambiente de produção, desenvolvimento, Q/A e outros. Dessa forma temos o controle total de qual versão está em cada ambiente. -
Dependências
As dependências devem ser declaradas e isoladas em um gerenciador de projetos. Elas não podem impactar no ambiente em que a aplicação for implantada, por isso o gerenciador de projetos, por exemplo, Maven, impede que uma aplicação seja executada com dependências de diferentes versões mesmo estando em ambientes distintos. -
Configuração
Devemos armazenar as variáveis de configurações e parâmetros no ambiente ou em um arquivo externo e não no código. Com isso, é possível enviar informações diferentes para cada tipo de ambiente. O ambiente de desenvolvimento não precisa conhecer os valores das variáveis do ambiente de produção. Podemos até agrupar as configurações por ambiente de implantação. -
Serviços de apoio
São recursos ligados à aplicação, como banco de dados, microsserviços, message brokers. As URLs desses serviços podem estar no arquivo de configuração. -
CI/CD
Processos de integração contínua, entrega contínua e implantação contínua, ou seja, construir, lançar e executar. Precisamos separar esses processos e executá-los em estágios. Geralmente esses processos possuem a partida através de um commit ou até de um processo agendado. Esses processos em conjunto com outros como testes unitários, agilizam a entrega das funcionalidades da aplicação. -
Stateless
A aplicação não deve guardar estado, ela deve ser executada por processos independentes. Um processo que está iniciando não pode depender de nenhum dado de outro processo. No máximo, esses dados podem ser armazenados em um serviço de mensageria ou no banco de dados. -
Vínculo de porta
Os consumidores da nossa aplicação não devem saber a porta real onde ela está sendo executada. A ideia é realizar uma ligação entre a porta real do serviço e uma porta externa que será utilizada pelos consumidores. Assim garantimos o isolamento e segurança da aplicação. -
Escalabilidade
Podemos escalar a aplicação conforme a quantidade de clientes que está utilizando. Para isso, utilizamos balanceadores de carga para distribuir as requisições entre os vários contêineres em execução. Podemos até ter balanceadores de carga para cada camada, por exemplo, camada web, camada da aplicação e camada do banco de dados. -
Descartabilidade
Precisamos que a aplicação inicie e desligue de forma rápida, essa é a ideia da descartabilidade. Essa velocidade garante que não haja impacto, por exemplo na troca dos servidores durante a atualização das versões, na escalabilidade ou elasticidade da aplicação. Em casos excepcionais onde o processo precisa ser mais lento, podemos utilizar mensageria para guardar uma informação que será processada quando a aplicação estiver disponível. -
Paridade Produção/Desenvolvimento
Devemos fazer o máximo possível para que os ambientes de desenvolvimento, testes e produção sejam iguais ou que pelo menos tenham mínimas diferenças para mitigar os imprevistos ao atualizar uma versão. -
Logs
Devemos tratar os logs como fluxos contínuos. Existem bibliotecas que armazenam os logs em arquivos à parte ou até mesmo em serviços na nuvem. Essa ideia é para que a geração de logs não afete o desempenho da aplicação. -
Processos administrativos
A aplicação não deve ser afetada por causa de processos administrativos, como por exemplo, migração de banco de dados, scripts executados periodicamente, exclusão de dados antigos, dentre outros.