12 Factor Apps

12 Factor Apps

Palestra feita na empresa MT4 Tecnologia sobre 12 Factor Apps (https://12factor.net/)

375596b28a94ecfaec5d63ff64c7f948?s=128

Vinícius Campitelli

May 24, 2018
Tweet

Transcript

  1. THE TWELVE-FACTOR APP 12factor.net

  2. OLÁ :) Vinícius Campitelli vsilva@mediapost.com.br Tech lead na @MediaPost 2

  3. ▪ Codebase ▪ Dependencies ▪ Config ▪ Backing services ▪

    Build, release, run ▪ Processes ▪ Port binding ▪ Concurrency ▪ Disposability ▪ Dev/prod parity ▪ Logs ▪ Admin processes 3
  4. 1. CODEBASE 4 ▪ Utilizar sistemas de controle de versão

    ▪ Apartar serviços em repositórios diferentes ▪ Relação um-a-um entre código e aplicação ▫ Mais de uma base → sistema distribuído ▪ Várias aplicações usando o mesmo código viola o manifesto
  5. 2. DEPENDENCIES ▪ Declarar explicitamente e isolar dependências ▫ Códigos

    e bibliotecas ▫ Serviços e pacotes do sistema ▫ Exemplos: curl, ImageMagick ▪ Utilizar ferramentas para gerenciá-las ▫ Exemplos: composer, Gemfile, npm 5
  6. 3. CONFIG ▪ Isolar configurações que podem sofrer alterações entre

    deploys ▪ Armazená-las em variáveis de ambiente ▫ Por que não arquivos? ▫ Podem ser acidentalmente incluídos no VCS ▫ Geralmente acoplados à linguagem e/ou SO ▫ Dica de pacote: dotenv 6
  7. 4. BACKING SERVICES ▪ Serviços consumíveis via rede devem ser

    tratados como recursos “acoplados” ▪ Substituir um serviço local por um remoto (ou vice-versa) não deve precisar gerar mudanças de código ▫ Exemplos: bancos de dados, gerenciador de filas, caching 7
  8. 5. BUILD, RELEASE, RUN ▪ Separar estágios de deploy ▫

    Build: transformação do repositório em um pacote executável ▫ Release: combinação do build com a configuração do ambiente ▫ Run: execução da aplicação e dos processos necessários 8
  9. 6. PROCESSES ▪ A aplicação deve ser executada como processo(s)

    stateless ▫ Arquitetura share-nothing ▫ Persistência deve ser mantida em backing services ▫ Nem mesmo sistema de arquivos local 9
  10. 7. PORT BINDING ▪ Exporte serviços em portas ▫ A

    aplicação deve escutar e processar requisições que chegam ▫ Princípio para se ter uma arquitetura orientada a serviços 10
  11. 8. CONCURRENCY ▪ Crie aplicações que podem ser escaláveis horizontalmente

    ▫ Separe tipos de processo diferente para ter regras escaláveis diferentes ▫ Se necessário, utilize serviços de fila ▫ Exemplos: RabbitMQ, Amazon SQS, Gearman 11
  12. 9. DISPOSABILITY ▪ Processos são descartáveis ▫ Início rápido ▫

    Desligamento amigável ▫ Robustos contra término inesperado 12
  13. 10. DEV/PROD PARITY ▪ Mantenha os ambientes o mais similar

    possível 13
  14. 11. LOGS ▪ Devem ser considerados como streams agnósticas ▪

    Não é da responsabilidade da aplicação gerenciar modo e destino do log 14
  15. 12. ADMIN PROCESSES ▪ Execute tarefas administrativas e de gerenciamento

    no mesmo ambiente em que sua aplicação principal ▫ Também devem ser adicionados ao VCS 15
  16. 16 OBRIGADO!