A nuvem reduziu as dificuldades para que possamos desenvolver aplicações robustas e escaláveis. O time-to-market é potencialmente menor visto que podemos alocar recursos facilmente, na medida em que são necessários. Entretanto, demanda cuidados.

Implementações ingênuas geram desperdícios e custos desnecessários, além de problemas de desempenho, segurança e confiabilidade. As arquiteturas de aplicações para a nuvem devem ser sensíveis a suas peculiaridades e, nesse contexto, se beneficiam se estiverem em conformidade com a metodologia The Twelve-Factor App – um conjunto de 12 fatores (orientações), elaborado em 2011 por um dos fundadores da Heroku.

Aplicações na nuvem, por exemplo, precisam lidar com falhas e demandas por elasticidade. Por isso, necessitam ser ágeis para descartar e alocar recursos, sobretudo em cenários onde aplicamos o conceito de infraestrutura imutável. A metodologia provê boas orientações para esses cenários, tanto no fator nove (que trata, exatamente, da descartabilidade) quanto no fator seis (que indica que processos devem executar sem armazenar estado, ou seja, stateless)

Os processos de um app doze-fatores são descartáveis, significando que podem ser iniciados ou parados a qualquer momento. Isso facilita o escalonamento elástico, rápido deploy de código ou mudanças de configuração, e robustez de deploys de produção.

Processos devem empenhar-se em minimizar o tempo de inicialização. Idealmente, um processo leva alguns segundos do tempo que o comando de inicialização é executado até o ponto que ele estará pronto para receber requisições ou tarefas. Períodos curtos de inicialização provém mais agilidade para o processo de release e de escalonamento; e ele adiciona robustez, pois o gestor de processos pode mais facilmente mover processos para outras máquinas físicas quando necessário.

(The Twelve-Factor App)

Os ambientes de nuvem, também peculiares, devem ser flexíveis e adaptáveis a demanda, utilizando estratégias como o auto-scaling. Novamente as orientações do fator seis são cruciais, assim como os do fator oito (que indica que a aplicação deve ser “fragmentada” em processos distintos e pequenos).

(…) processos são cidadãos de primeira classe. Processos na aplicação doze-fatores utilizam fortes sugestões do modelo de processos UNIX para execução de serviços daemon, o desenvolvedor pode arquitetar a aplicação dele para lidar com diversas cargas de trabalho, atribuindo a cada tipo de trabalho a um tipo de processo. Por exemplo, solicitações HTTP podem ser manipuladas para um processo web, e tarefas background de longa duração podem ser manipuladas por um processo trabalhador.

(The Twelve-Factor App)

Demandas por controle operacional incitam a adoção da gestão da infraestrutura como código. Além disso, é importante que mitiguemos as diferenças do ambiente de produção com o de desenvolvimento para maior consistência e qualidade. Assim, ao utilizar um VCS para armazenar os fontes de um projeto de infraestrutura, como prescrito no fator um, traremos consistência aos templates criados e deixaremos explicitas as suas dependências, como prescrito no fator dois. Além disso, através de um pipeline de CI/CD bem elaborado, ficará mais fácil separar os estágios de construção e execução, como previsto no fator cinco. Estes templates e pipelines podem ser reutilizados para criar diversos ambientes diferentes embora consistentes entre si, conforme indicado no fator dez, apenas variando em configuração, que são específicas para cada um, conforme o fator três.

Historicamente, houveram lacunas substanciais entre desenvolvimento (um desenvolvedor editando código num deploy local do app) e produção (um deploy acessado pelos usuários finais). Essas lacunas se manifestam em três áreas:

• A lacuna do tempo: Um desenvolvedor pode trabalhar em código que demora dias, semanas ou até meses para ir para produção.
• A lacuna de pessoal: Desenvolvedores escrevem código, engenheiros de operação fazem o deploy dele.
• A lacuna de ferramentas: Desenvolvedores podem estar usando um conjunto como Nginx, SQLite, e OS X, enquanto o app em produção usa Apache, MySQL, e Linux.

O App doze-fatores é projetado para implantação contínua deixando a lacuna entre desenvolvimento e produção pequena. 

(The Twelve-Factor App)

Finalmente, aplicações em nuvem, por sua natureza distribuída, apresentam desafios importantes quanto a observabilidade. A metodologia colabora indicando, no fator onze, como logs devem ser construídos. Em resumo, a metodologia defende que são os ambientes, e não as aplicações, que devem estar encarregados de tratar o destino dos logs gerados. Considerando a natureza dinâmica de ambientes de nuvem, esta separação de responsabilidade resulta em portabilidade.

Um app doze-fatores nunca se preocupa com o roteamento ou armazenagem do seu fluxo de saída. Ele não deve tentar escrever ou gerir arquivos de logs. No lugar, cada processo em execução escreve seu próprio fluxo de evento, sem buffer, para o stdout. Durante o desenvolvimento local, o desenvolvedor verá este fluxo no plano de frente do seu terminal para observar o comportamento do app.

(The Twelve-Factor App)

Em síntese, os cuidados necessários são muitos e toda orientação qualificada é bem-vinda. The Twelve-Factor App é incrivelmente concisa e facilmente desperta atenção para pontos importantes – muitos dos quais não estão listados nesse post – e mitigam os riscos do desenvolvimento de aplicações para a nuvem.