Como vimos na primeira parte do nosso artigo, vimos sobre alguns fatores (Base de Código, Dependências, Configurações, Serviços de Apoio, Build, release, run) e para dar continuidade e finalizar os nossos 12 fatores que contribuem para uma aplicação SaaS de qualidade:
VI. Processos
“Execute a aplicação como um ou mais processos que não armazenam estado”
No caso mais simples, o código é um script autônomo, o ambiente de execução é o laptop local de um desenvolvedor com o runtime da linguagem instalado, e o processo é iniciado pela linha de comando (por exemplo, python my_script). Na outra extremidade do espectro, o deploy em produção de uma aplicação sofisticada pode utilizar vários tipos de processos, instanciado em zero ou mais processos em andamento. A maneira preferida de 12 fatores de empacotar seus ativos é durante o tempo de construção (mesclando todos os arquivos css em um, por exemplo).
Isso tem várias desvantagens – você não pode combinar ativos dinamicamente, por exemplo, se você tem 6 scripts, e uma página que você precisa 4, em outra página você precisa 2 dos utilizados na primeira página, e outro 2, então você tem que construir Todas essas permutações de antemão. O que é bom e funciona, mas por que é necessário? Não há benefício aparente. E dependendo das ferramentas que você usa, pode ser mais fácil trabalhar com CDN se você estiver gerando dinamicamente os bundles. De maneira resumida o que se aconselha é tomar cuidado com processos que tomam estado durante execução do código, para que isso não possa atrapalhar outros processos em execução.
VII. Vínculo de porta
“Exporte serviços por ligação de porta”
Trata-se de ter seu aplicativo como autônomo, em vez de depender de uma instância em execução de um servidor de aplicativos, onde você faz o deploy. Embora isso pareça mais fácil de gerenciar, não é. Iniciar um contêiner de servlet e realizar o deploy é facil. Mas, para que seu aplicativo se vincule a uma porta, você precisa ter o ferramental para isso. Num ambiente de desenvolvimento local, o desenvolvedor visita a URL de um serviço como http://localhost:5000/ para acessar o serviço exportado pelo seu app. Num deploy, uma camada de roteamento manipula as requisições de rotas vindas de um hostname público para os processos web atrelados às portas. Note que a abordagem de vincular portas significa que um app pode se tornar o serviço de apoio para um outro app, provendo a URL do app de apoio como um identificador de recurso na configuração para o app consumidor.
VIII. Concorrência
“Dimensione por um modelo de processo”
É sobre o uso de processos nativos. Qualquer programa de computador, uma vez executado, está representado por um ou mais processos. Isso, eu acho, não é tão relevante para um todas as linguagens, principalmente para as que usam threads sob um outro processo primário. A recomendação de forma resumida é tomar cuidado com concorrência entre processos que possam atrapalhar a execução e performance de outrem.
IX. Descartabilidade
“Maximizar a robustez com inicialização e desligamento rápido”
Isso é sobre abraçar o fracasso. Seu sistema deve funcionar bem mesmo que uma ou mais instâncias de aplicativo morram. E isso está prestes a acontecer, especialmente “na nuvem”. 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 o gestor de processos pode mais facilmente mover processos para outras máquinas físicas quando necessário.
X. Dev/prod semelhantes
“Mantenha o desenvolvimento, teste, produção o mais semelhante possível”
Seu ambiente de desenvolvimento deve ser quase idêntico a um de produção (por exemplo, para evitar alguns problemas “funciona na minha máquina”). Isso não significa que seu sistema operacional tem que ser o sistema operacional em execução na produção, no entanto. Você pode executar o Windows, por exemplo, e ter seu banco de dados, MQ, etc, executando em uma máquina virtual local. Isso também sublinha a independência do sistema operacional de sua aplicação. Basta ter em mente para manter as versões o mesmo.
XI. Logs
“Trate logs como fluxo de eventos”
A metodologia de 12 fatores recomenda a gravação de todas as informações de registro no sistema. Claro que você pode gerenciar os aspectos de registro no aplicativo, em vez de depender de ferramentas de terceiros para fazer isso, porém eu gosto muito do ELMAH. Pode haver configurações de log específicas do ambiente, que é novamente apenas um arquivo com informações sobre o assunto). Se isso parece complicado, considere as complicações de configurar o que quer que vai capturar a saída.
XII. Processos de Admin
“Executar tarefas de administração/gerenciamento como processos pontuais”
Processos de administração pontuais devem ser executados em um ambiente idêntico, como os processos regulares de longa execução da app. Eles rodam uma versão, usando a mesma base de código e configuração como qualquer processo executado com essa versão. Códigos de administração devem ser fornecidos com o código da aplicação para evitar problemas de sincronização. Geralmente concordado, mas, além disso, eu diria que é preferível executar migrações na implantação ou inicialização, em vez de manualmente, a fim de certificar-se de que é idêntico em todas instâncias da sua aplicação.
Fontes: https://12factor.net/pt_br/admin-processes / https://dzone.com/articles/the-12-factor-app-a-java-developers-perspective / https://pivotal.io/beyond-the-twelve-factor-app
O que você achou do 12 factor App? Comenta ai!
