Introdução ao 12 Factors APP

Para que serve a metodologia / guia Twelve Factors APP

1. Introdução aos 12 Fatores “12 Factors APP” Douglas Alonso

2. Arquiteto de Soluções – Itaú Unibanco Especializado em Engenharia de Software PUC-SP Graduado em Tecnologia e Desenvolvimento de Sistemas – IBTA SP Consultor de TI atuando a mais de 20 anos no mercado nacional participando de grandes projetos para grandes empresas. Douglas Alonso Cruz

3. Evolução dos sistemas Sistema Local Sistema em Rede Sistema em ambiente em Nuvem

4. Evolução das Arquiteturas Sistema Monolítico Sistema Micro Serviços Interface do Usuário Regras de Negócio Acesso a Dados Base de Dados Interface do Usuário Microserviço Clientes Microserviço Fornecedores Microserviço Estoque Microserviço Tabelas Microserviço Produtos Base de Dados Base de Dados Base de Dados Base de Dados Imaginando um Sistema de vendas

5. O que mudou? Vimos na imagem anterior que a complexidade aumentou, agora em vez de olhar para um sistema, passamos a ter que olhar para vários micro sistemas, com isso manter configurações, logs, métricas, código, testes ficou realmente mais trabalhoso e complicado.

6. Vamos falar do que interessa Twelve-Factor App é uma metodologia, é um guia usado para a construção de aplicações SAAS. A metodologia tem como base 12 fatores, ou melhor 12 práticas para permitir que aplicações sejam construídas tendo como objetivo portabilidade, resiliência, segurança, robustez entre outras características. E o que isso tem a ver com o cenário dos micro serviços? Todos os 12 fatores podem e devem ser usados no desenvolvimento dos micro serviços e na infra que serão executados. A quem se destina: Desenvolvedores que criam software como serviço, engenheiros de operações, arquitetos, afinal a todos que criam ou pretendem criar software de qualidade.

7. A metodologia Twelve-Factor foi criado na Heroku, empresa pioneira em hospedagem no mundo cloud. É independente de linguagem de programação e serve como um guia para desenvolvimento de aplicações com qualidade. Foi criada em 2011

8. I Code Base (Base de código) Utilizar uma base de código para rastreamento e controle de revisão da aplicação. Ter apenas uma base de código por aplicação , sempre tem que haver essa relação de 1 pra 1 , uma base de código para uma aplicação. Se existirem várias bases de código isso não é uma aplicação e sim um sistema distribuído, já o inverso onde múltiplas aplicações compartilham uma base de código também fere a metodologia e não deve ser usado.

9. II Dependencies (Dependências) Bibliotecas A sua aplicação deve ser autocontida ou seja dentro do seu container ou pacote ela precisa ter todas as bibliotecas ou pacotes necessários para o seu funcionamento. Ferramentas como (Npm, yarn, maven, nuget, grade) ajudam neste gerenciamento. Porém também existem outros tipos de dependências como conexões com banco de dados, serviços, que podem nos causar problemas, neste caso ferramentas como Chef, Puppet, Docker e Kubernetes. Tendo as dependências declaradas facilitará também no sentido de integração de novas pessoas na equipe, rodando apenas um comando no terminal, teremos a aplicação rodando e o ambiente configurado.

10. III Config (Configurações) A 1ª recomendação é que as configurações e o codigo fonte e sejam totalmente separados um do outro. As configurações podem ser armazenadas em variáveis de ambiente, variáveis de ambiente são pertinentes ao host onde a aplicação está hospedada, deste modo não corre o risco de alguém sobrepor um arquivo com caminho errado etc. As configurações jamais devem ser mantidas em repositório pois contém dados sensíveis e podem impactar na segurança da empresa. Armazenar configurações em código como constantes também fere a metodologia e não deve ser usado. Uma maneira muito simples de verificar se seu aplicativo segue este princípio de  configuração  ou não é: Perguntando-se se você pode tornar seu aplicativo de código aberto agora, sem fazer nenhuma alteração e sem comprometer nenhuma de suas credenciais. Set Env APPLICATION_ENV “development”

11. IV Backing services ( Serviços de apoio) Trate serviços de apoio como recursos anexados Um serviço de apoio é qualquer serviço que o app consuma via rede como parte de sua operação normal. Exemplos incluem armazenamentos de dados (como MySQL ou MongoDB), sistemas de mensagens/filas (tais como RabbitMQ), serviços SMTP para e-mails externos (tais como Sendgrid), e sistemas de cache (tais como Redis). O código para um app doze-fatores não faz distinção entre serviços locais e de terceiros.  Para o app, ambos são recursos anexados, acessíveis via uma URL ou outro localizador/credenciais na  config . Um  deploy  do app doze-fatores deve ser capaz de trocar um banco de dados MySQL por um gerenciado por terceiros (tais como  Amazon RDS ) sem realizar quaisquer mudanças no código do app. Em ambos os casos, apenas o identificador de recurso precisa mudar.

12. V Build, Release, Run (Construa, libere, execute) Uma base de código é transformada em um deploy geralmente por três estágios: Build  consiste em pegar uma versão especifica do repositório com suas dependências e transforma-la em uma versão executável, funcional, seja por compilação ou empacotamento; Release  consiste no envio de um build para um servidor e a execução de todas as configurações necessárias para que ele entre no terceiro estágio Run   é a inicialização de todos os processos necessários para que ele esteja disponível para os usuários acessarem. JENKINS

13. VI Process (Processos) Execute o aplicativo como um ou mais processos sem estado. Um aplicativo segue este princípio se suas instâncias podem ser criadas e destruídas a qualquer momento sem afetar a funcionalidade geral de nosso aplicativo. Interface do Usuário Microserviço Clientes Microserviço Vendas Microserviço Estoque Microserviço Tabelas Microserviço Produtos Base de Dados Base de Dados Base de Dados Base de Dados Interface do Usuário Microserviço Clientes Microserviço Vendas Microserviço Estoque Microserviço Tabelas Microserviço Produtos Base de Dados Base de Dados Base de Dados Base de Dados Microserviço Vendas Microserviço Vendas Microserviço Vendas

14. VII Port Binding (Atribuição a portas) A ideia é que o projeto não dependa de um servidor externo como o Apache ou IIS por exemplo para ser executado, mas que possa ser auto-contido e executar em uma porta específica que seria acessado por outras partes do projeto ou mesmo pelos usuários. http://localhost:7195

15. VIII Concurrency (Concorrência) Tente pensar em seu projeto na forma de processos, como citado anteriormente, que podem ser executados em paralelo. Chamadas http não demoradas podem ser resolvidas pelo servidor web de forma rápida e devolvida para o cliente, porém tarefas mais demoradas podem ser enviadas para mecanismos de filas que executarão o processamento em background sem travar sua aplicação e retornarão a informação assim que o processamento for concluído. Este segundo modo permite que processamento sejam executados em paralelo.

16. IX Disposability (Descartabilidade) 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. Lembra da imagem dos nossos micro serviços Em dado momento preciso executar um processo grande e demorado para calcular meu estoque no final do mês, neste caso subiria mais instâncias do micro serviço de vendas e estoque. Terminado o calculo poderia simplesmente derrubar essas instancias. Outro exemplo, um micro serviço travou. O sistema deve derrubar matar esse processo e subir um novo.

17. X Dev / Prod parity (Igualdade de ambiente) Os ambientes de produção, homologação e desenvolvimento devem ser o mais similares possíveis. Facilitando assim os processos de Deploy Continuo.

18. XI Logs Os logs são uma importante ferramenta para entender o comportamento de um projeto, identificando erros e pontos de melhoria . O fluxo de evento para um app pode ser direcionado para um arquivo, ou visto em tempo real via tail num terminal. Mais significativamente, o fluxo pode ser enviado para um sistema indexador e analisador tal como Splunk,

19. XII Admin Process – Processos Administrativos Tarefas administrativas devem ser tratadas de forma automatizada. Como agora nosso projeto pode rodar em diversos servidores, com diversos processos, coisas como limpar caches, carregar dados, atualizar bases de dados, etc, também devem ser facilitadas. As linguagens modernas geralmente tem um CLI (Command Line Interfaces) e através de comandos podemos executar e automatizar muitas coisas, se juntarmos isso a ferramenta de pipeline como Jenkins, O AWS Pipeline, o Azure Pipelines o cenário fica melhor ainda. O fluxo de evento para um app pode ser direcionado para um arquivo, ou visto em tempo real via  tail  num terminal. Mais significativamente, o fluxo pode ser enviado para um sistema indexador e analisador tal como  Splunk , O fluxo de evento para um app pode ser direcionado para um arquivo, ou visto em tempo real via  tail  num terminal. Mais significativamente, o fluxo pode ser enviado para um sistema indexador e analisador tal como  Splunk ,

20. https://12factor.net/pt_br/ Documentação Oficial 12 Fatores As informações contidos aqui no 12 fatores é o básico do que temos que pensar para ter um produto / sistema de qualidade, existem muitas outras preocupações a serem tomadas, mas fica para uma próxima conversa. Se quiserem conhecer um pouco mais procurem pelo termo Engenharia da Confiabilidade ou SRE https://srebrasil.com/

21. Obrigado Douglas Alonso Cruz [email protected] https://www.linkedin.com/in/douglasalonso/ Raphael Freitas [email protected] https://www.linkedin.com/in/raphael-Freitas-santos