A metodologia dos 12 fatores define um modelo para o desenvolvimento e entrega de uma aplicação web saudável e escalável.

O desenvolvimento de uma aplicação web envolve processos de virtualização, entrega e configurações de ambientes de desenvolvimento e recursos de apoio (banco de dados, redes, etc…).

Embora a metodologia não elimine esta complexidade, ela fornece um framework de trabalho para organizar o projeto.

Portanto, ela é um material de apoio para a definição da melhor estratégia de desenvolvimento e entrega.

Benefícios dos 12 Fatores

Aplicar os 12 fatores no desenvolvimento de uma aplicação web envolve utilizar as seguintes diretrizes:

• Primeiramente, utilizar formatos declarativos para automação de ambiente, minimizando os custos de entrada de novos desenvolvedores no projeto;
• Em segundo lugar, estabelecer um contrato claro com o ambiente operacional, oferecendo o máximo possível de portabilidade entre ambientes;
• Então, focar na entrega em ambientes cloud, minimizando a necessidade de servidores e operadores de infraestrutura;
• Após isto, minimizar a divergência entre ambientes de desenvolvimento e produção através da entrega contínua;
• Finalmente escalar a aplicação sem mudanças significativas de ferramentas, arquitetura ou práticas de trabalho;

Além do mais, a metodologia dos 12 fatores pode ser aplicada em qualquer linguagem e em combinação com qualquer serviço de apoio: banco de dados, filas, cache, etc…

Fator 1 – “CodeBase”

“Código fonte gerenciado por um controle de revisão e diversos ‘deploys’.”

O código fonte deve ser gerenciado por um sistema de controle de código centralizado em local específico denominado “repositório”.

Porém, haverá diversas versões da mesma aplicação em diferentes ambientes, representando uma visão específica do sistema em um determinado momento.

Portanto, apesar de cada ambiente possuir uma versão executável com funcionalidades distintas, todas são oriundas de um mesmo código-fonte ou mais especificamente, mesmo repositório.

Fator 2 – “Dependencies”

“Declarar e isolar dependências explicitamente.”

A aplicação poderá depender de pacotes e bibliotecas mas nunca deverá assumir a pré existência deles nos ambientes em que será executada.

Em outras palavras, a aplicação deverá declarar as dependências e delegar para outros componentes a resolução destas dependências. Entretanto, os ambientes de execução podem ser agnósticos referente a estas tecnologias de apoio.

Neste contexto, o pipeline de entrega contínua deverá garantir o provisionamento das ferramentas de apoio para correta instalação e execução das aplicações.

Fator 3 – “Configuration”

“Armazenar a configuração no ambiente”.

As opções de configuração do sistema não devem ficar no código-fonte. Os principais motivadores para evitar isto são:

• Primeiramente evitar que informações confidenciais estejam disponíveis no código-fonte. Ex: credenciais de banco ou serviços;
• Em segundo lugar, as configurações variam por ambiente, portanto o commit de informações relativas a um ambiente podem influenciar negativamente outro ambiente;

Portanto, a aplicação deverá utilizar as variáveis de ambiente em conjunto com serviços responsáveis por armazenar valores de configuração de maneira que seu uso fique transparente para os desenvolvedores e para a aplicação.

Fator 4 – “Backing Services”

“Tratar serviços de apoio como recursos anexos”.

Um serviço de apoio é qualquer serviço utilizado pela aplicação através da rede. Por exemplo, banco de dados, cache, message brokers, etc…

Do ponto de vista da aplicação, estes recursos podem ser vinculados ou não na aplicação a qualquer instante, sem que isto gere mudanças no código-fonte. Consequentemente, o acesso a estes recursos devem estar disponíveis através de configurações.

Fator 5 – “Build, Release and Run”

“Separar completamente etapas de construção e execução”.

As etapas de construção, disponibilização e execução de um sistema devem ser separadas pelos seguintes motivos:

• A etapa de construção é controlada completamente pelo desenvolvedor. Nela são aplicados tags de novas versões e/ou correção de bugs;
• A etapa de lançamento prepara o código para execução em um determinado ambiente. Nesta etapa são executados testes para validar o comportamento da aplicação;
• A etapa de execução disponibiliza o software para uso e geralmente não demanda intervenção;

Como resultado, é necessário utilizar ferramentas de automação para garantir que cada uma das etapas seja executada de forma transparente e o mais rápida possível.

Fator 6 – “Processes”

“Executar a aplicação com um ou mais processos sem estado”.

A metodologia dos 12 fatores entende que aplicações devem degradar de maneira imperceptível. Portanto, caso a aplicação necessite de alguma informação compartilhada ela deve obter de outro serviço.

Em outras palavras, dados do estado da aplicação não devem ser usados com a intenção de compartilhamento com outros processos.

Fator 7 – “Port Binding”

“Expor serviços através de portas específicas”.

As aplicações web devem ser auto-contidas, ou seja, “containerizadas”. Em outras palavras, toda infraestrutura para expor suas funcionalidades devem estar disponíveis através de uma porta específica.

Portanto, as funcionalidades devem estar disponíveis através de um endereço URL como por exemplo “http://localhost:5000”.

Do mesmo modo, o processo de deploy irá direcionar as requisições a partir de uma camada de roteamento no momento que a aplicação tiver que ser acessada publicamente.

Fator 8 – “Concurrency”

“Dimensionar a aplicação através de um modelo de processo”

Toda aplicação em execução corresponde a um ou mais processos em memória. Do ponto de vista da metodologia dos 12 fatores, os processos são atores principais.

Consequentemente, cada funcionalidade da aplicação deve ser modelada de forma que seja atendida por um ou mais processos que possam escalar, reiniciar ou se clonar independentemente quando necessário.

Fator 9 – “Disposability”

“Tornar o sistema mais robusto com inicialização rápida e finalização elegante”.

Um processo ser “descartável” significa que ele pode ser iniciado ou terminado sem grandes impactos no tempo de execução da aplicação ou disponibilização das suas funcionalidades.

Acima de tudo, isto permite escalabilidade mais rápida, entregas de código mais ágeis ou reconfiguração de aplicação sem grandes impactos.

Fator 10 – “Dev/Prod Parity”

“Manter os ambientes de desenvolvimento, testes e produção mais parecidos possíveis”.

Os ambientes nos quais a aplicação será executada deverão possuir o mesmo sistema operacional, os serviços de apoio e as mesmas dependências.

Contudo, historicamente há “gaps” que costumam manifestar-se em três áreas:

• Em primeiro lugar, o “gap temporal”: o desenvolvedor trabalha em código que irá levar dias, semanas ou meses até ir para produção;
• Em segundo lugar, o “gap de papéis”: o desenvolvedor codifica e o profissional de operações implanta;
• Finalmente, o “gap de ferramentas”: os recursos usados em desenvolvimento divergem dos recursos existentes no servidor. Por exemplo, versões diferentes de banco de dados;

Portanto, a metodologia dos 12 fatores sugere as seguintes ações para minimizar os efeitos destes gaps:

1. Reduzir o tempo entre deploy para horas no lugar de dias, semanas ou meses;
2. Permitir que as mesmas pessoas que codificam sejam responsáveis pela implantação da aplicação até produção;
3. Nivelar os ambientes da aplicação, objetivando manter somente diferenças no que se refere a necessidade de carga ou performance devido a volume de utilização e/ou requisitos específicos de compliance, por exemplo.

Fator 11 – “Logs”

“Tratar logs como um fluxo de eventos”.

Logging da aplicação possui um papel fundamental no debug ou na avaliação da saúde geral da aplicação. Porém, os logos fornecem uma visão comportamental da aplicação.

Logs, em última instânciam são fluxos de informações ordenadas temporalmente que não devem ser um item de preocupação da aplicação.

Em outras palavras, a aplicação não deve ser responsável pelo armazenamento e o gerenciamento dos logs.

A metodologia dos 12 fatores sugere que os logs sejam roteados para um serviço específico responsável pelo seu armazenamento, indexação e exposição de funcionalidades analíticas para extração de valor.

Por exemplo, ferramentas como o New Relic, LogEntries ou plataforma ELK têm esta capacidade.

Fator 12 – “Admin Processes”

“Executar tarefas de administração como processos únicos”.

Tarefas de administração e gerenciamento da aplicação envolvem atividades relativas a migração de banco de dados, obtenção de dados para realização de análises, ou executar scripts específicos ao contexto do sistema, dentre outros.

A metodologia dos 12 fatores sugere que estes processos sejam executados em um ambiente semelhante ao ambiente no qual a aplicação é executada. Em outras palavras, eles são executados sobre o mesmo código-fonte, configurações e mecanismos de persistência.

Portanto, a tarefas de administração devem ser empacotadas e entregues junto com o código fonte responsável pela entrega de funcionalidades de uma determinada versão da aplicação.

Conclusão

Apesar de não ser possível identificar todos os tipos de problemas que podem envolver a criação de uma aplicação web, a metodologia dos 12 fatores fornece um vocabulário comum para discutir e endereçar caminhos para a resolução de alguns problemas.

Além disso, é possível aplicar a metodologia dos 12 fatores em conjunto com padrões de projeto de Arquitetura de Software. Caso deseje saber mais sobre padrões de projeto, clique aqui.

Referências

“12-Factor App Methodology” (https://www.joomlatools.com/developer/platform/12-factor-app/)

“The Twelve -Factor App” (https://12factor.net/)