Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

12 Factor App TDC São Paulo 2018

54 views

Published on

Que decisões são relevantes no início do projeto para que a aplicação seja portável, escalável, pronta para a nuvem e "production ready" desde as primeiras features? A metodologia dos 12 fatores sintetiza esse assunto de maneira didática.

Published in: Technology
  • Be the first to comment

12 Factor App TDC São Paulo 2018

  1. 1. Boas práticas na construção de serviços 1
  2. 2. Grazi Bonizi Coordeno a trilha de Arquitetura .Net no The Developers Conference, compartilho código no GitHub, escrevo no Medium e no Blog da Lambda3, e participo de Meetups e PodCasts normalmente sobre DevOps, Azure, .Net, Docker e DDD Consultora DevOps na Lambda3 Este é um exemplo de subtítulo. https://twitter.com/GraziBonizi https://github.com/grazibonizi https://www.linkedin.com/in/graziella-bonizi-b14835a0/ https://www.lambda3.com.br/L3/graziella-bonizi/ 2
  3. 3. Conteúdo 1 Origem, princípios e fatores 2 Fatores de Design 3 Fatores de Build & Release 4 Fatores de Gerenciamento 5 Próximos passos Quais são nossas principais preocupações ao construir uma aplicação? Que decisões valem a pena ser tomadas no início do projeto para que a aplicação esteja "production-ready" desde as primeiras features? Ao longo da palestra vamos entender como os princípios da 12 Factor Apps podem implementados para que a aplicação seja escalável, íntegra e gerenciada adequadamente. Porque 12 factor app? 12 Fator App é uma metodologia bem didática que reúne boas práticas para construção de serviços, muito relacionado a desenvolvimento moderno, containers, DevOps e plataforma em nuvem. O objetivo hoje é mostrar como o 12 Factor App pode guiar a construção de serviços prontos para serem publicados desde as primeiras versões. Os fatores foram agrupados em três assuntos: • Fatores de Design, que estão relacionados ao desenvolvimento e arquitetura da aplicação em si, • Fatores de Build & Release, que observam as práticas de integração e entrega contínuas • e Fatores de Gerenciamento, relacionados à administração e ao monitoramento da aplicação em execução. Para encerrar, vou outros dois fatores que talvez fizessem parte da metodologia se ela fosse elaborada hoje, e vou demonstrar uma aplicação em .NET que cumpre os 12 fatores. 3
  4. 4. 12 Factor App: Origem, Princípios e Fatores 4
  5. 5. Origem a lenta deterioração do software ao longo do tempo que acabará por torná-lo inutilizável. O software não decai, mas sofre com a falta de atualização em relação à mudança ambiente em que reside” “Erosão de software é • Metodologia criada pelos colaboradores da plataforma Heroku, em particular o co-fundador Adam Wiggins; • Heroku é uma plataforma PAAS poliglota; • O time criou a metodologia com base na sua experiência no que contribuiu para o sucesso e resistência à erosão do Heroku. • É destinada à construção de serviços, independente de linguagem e plataforma Em 2006, Adam Wiggins, fundador dos 12 fatores, criou uma aplicação web simples e a compartilhou com alguns amigos. Ele deixou de utilizá-la, mas seus amigos continuaram. Dois anos depois ele foi notificado que o site estava fora do ar. Logando no servidor com ssh, ele descobriu que: • O processo da aplicação tinha quebrado e não reiniciou; • A utilização do disco tinha atingido 100% por causa dos arquivos de log e dados de sessão; • O kernel, ssh, openssl e apache precisavam de atualizações de segurança críticas; • A distribuição do linux tinha sido descontinuada, e não possuía as atualizações de segurança necessárias. Ele tentou migrar a aplicação para outra VM com um Sistema Operacional atualizado, mas a aplicação quebrou por uma série de motivos, como apontamentos locais que eram diferentes neste Sistema Operacional, e mudanças em dependências externas. Em resumo, a aplicação atingiu um estado não funcional, sem nenhuma alteração no código que estava funcionando. Ele tinha acabado de vivenciar um caso impactante de Erosão de Software. 5
  6. 6. • Usam formatos declarativos para automatizar a configuração inicial, minimizar tempo e custo para novos desenvolvedores participarem do projeto; • Tem um contrato claro com o sistema operacional que o suporta, oferecendo portabilidade máxima entre ambientes que o executem; • São adequados para implantação em modernas plataformas em nuvem, evitando a necessidade por servidores e administração do sistema; • Minimizam a divergência entre ambientes, como desenvolvimento e produção, permitindo a implantação contínua para máxima agilidade; • E podem escalar sem significativas mudanças em ferramentas, arquiteturas, ou práticas de desenvolvimento. É uma metodologia para construir softwares- como-serviço que: 6
  7. 7. Os fatores 1 Codebase 2 Dependencies 3 Config 4 Backing services 5 Build, release, run 6 Processes 7 Port binding 8 Concurrency 9 Disposability 10 Dev/prod parity 11 Logs 12 Admin processes 7
  8. 8. Fatores de Design 8
  9. 9. Port Binding • Self-Hosted Apps: a aplicação deve ser capaz de inicializar e ouvir e responder a uma porta • O HTTP Server deixa de ser um elemento externo e passa a ser uma dependência da aplicação Exporte os serviços via port binding Tradicionalmente as aplicações eram compiladas e publicadas em WebServers externos, como IIS e Apache. Com o desenvolvimento moderno, os webservers deixam de ser um elemento externo e passam a fazer parte da aplicação como dependência. O efeito é a aplicação ser auto-contida, isto é, capaz de se “hospedar” sozinha e ser executada como um processo web vinculado a uma porta. No ambiente de desenvolvimento, o programador acessa a URL local, como http://localhost:5000, e no ambiente de deploy, uma URL pública é vinculada à URL local, como http://www.12factor.net . 9
  10. 10. Processes and concurrency • Não dependa de sessões ou dados armazenados no ambiente • Informações de sessão devem ser armazenadas numa Store externa • Mais de um serviço deve poder ser instanciado sem impacto no funcionamento da aplicação Execute a aplicação como um ou mais serviços sem estado Ainda muito relacionado ao fator Port-Binding, os fatores Processes e Concurrency permitem que a aplicação seja escalada verticalmente (várias instâncias na mesma máquina) e horizontalmente (várias instâncias em máquinas diferentes). A aplicação é executada como um processo que não compartilha estado, portanto, pode ser gerenciada isoladamente. 10
  11. 11. Backing Services • Serviços devem ser configurados via um único ponto de entrada • O apontamento deve ser externo, como uma URL em um arquivo de configuração Trate o consumo de serviços como recursos atachados Os serviços que a aplicação consome, como banco de dados, provedores de email e etc devem poder ser “atachados” ou “desatachados“ facilmente por meio de um único ponto de entrada, normalmente uma URL, com seu apontamento em um arquivo de configuração 11
  12. 12. Disposability • Os ambientes devem poder ser descartados e escalados sempre que necessário • A aplicação deve poder trocar de ambiente sem impacto no funcionamento Maximize a robustez com startups rápidos e “graceful shutdowns” “Servidores não são bichinhos de estimação” Originalmente, devido ao modelo de desenvolvimento e operações, os servidores eram tratados com “carinho”. O custo operacional e financeiro para trocar a aplicação de ambiente era alto. No desenvolvimento moderno, as aplicações podem ser facilmente trocadas de ambiente caso haja a necessidade. Utilizando infraestrutura como serviços a velocidade para realocar aplicações saindo de um servidor com problemas para um saudável é mínima. Com Plataforma como Serviços (PaaS) ou orquestradores de containers, como Kubernetes, isso é feito automaticamente sem a necessidade de intervenção manual. Isso é possível porque ao cumprir os 12 fatores, os processos de aplicação são descartáveis, rápidos para inicializar e “graciosos ao encerrar”. No caso de processos web isso implica em finalizar as requisições em execução adequadamente sem deixar processos presos, conexões abertas ou “rastros”. As aplicações também são preparadas para lidar com interrupções súbitas. 12
  13. 13. Fatores de Build & Release 13
  14. 14. Codebase • Use um versionador de código (git) • Aplicações que possuem ciclos de vida distintos devem estar em repositórios distintos • O que é promovido é o artefato, não o código • Escolha uma estratégia de branches adequada • Configure a integração contínua Uma única base de código rastreada em um sistema de revisão com múltiplos deploys Existe sempre uma correlação um-para-um entre a base de código e a aplicação: • Se existem várias bases de código, isto não é uma app – é um sistema distribuído. Cada componente do sistema é uma app, e cada uma pode individualmente ser compatível com os 12 fatores. • Múltiplas apps compartilhando uma base de código é uma violação dos 12 fatores. A solução aqui é dividir o código compartilhado entre bibliotecas que podem ser incluídas através do gerenciador de dependências. 14
  15. 15. Dependencies • Deixe claro quais dependências e versões sua aplicação utiliza • Não utilize dependências compartilhadas entre aplicações (GAC, Com+) • Isole o ambiente da aplicação Declare de forma explícita e isole as dependências As dependências da aplicação e suas versões estão claramente enumeradas (packages.json, arquivos pom, etc). Não utilize dependências compartilhadas. Quando mais de uma aplicação utiliza a mesma dependência no sistema operacional, a atualização de uma pode impactar na outra. Isso facilita o setup da aplicação na máquina de desenvolvimento, por exemplo. Após obter o código, executar um comando simples, como nuget restore ou npm install será o suficiente para baixar todas as dependências corretas e deixar a aplicação pronta para ser compilada. 15
  16. 16. Config • Não utilize apontamentos e varíaveis de uma forma que seja necessária a recompilação da aplicação • As configurações que dependem do ambiente em que a aplicação será publicada devem ser isoladas para o ambiente em questão • Utilize variáveis de ambiente, arquivos ou serviços externos de configuração • Se você fosse abrir o código da sua aplicação hoje, alguma informação confidencial seria comprometida? Armazene a configuração do ambiente no próprio ambiente 16
  17. 17. Build, Release, Run • Release: Artefato de Build + Parâmetros, arquivos de configuração e secrets relativos ao ambiente Separe os estágios de construção e execução Uma base de código é transformada num deploy através de três estágios: • Build: O estágio de construção é uma transformação que converte um repositório de código em um pacote executável, ou artefato. • Release: O estágio de entrega obtém o artefato produzida pelo estágio de construção e o combina com a configuração atual do ambiente em que será publicado, resultando em uma aplicação pronta para ser executada. • Run: O estágio de execução roda o app no ambiente de execução, através do início de alguns dos processos do app com um determinado artefato. Com a implementação adequada de integração contínua e entrega contínua, o artefato é rastreado facilmente à versão de código que o gerou. 17
  18. 18. Dev/Prod Parity • Ambiente de desenvolvimento, testes e produção deve ser tão compatível quanto possível • Mesmas dependências e serviços consumidos • Base de código deve ser semelhante à produção (Continuous Deployment) • Desenvolvedores devem estar próximos do deploy Mantenha o desenvolvimento, homologação e produção tão similares quanto possível Historicamente, houveram lacunas substanciais entre desenvolvimento (um desenvolvedor codificando) e produção (a aplicação disponível para os 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. Olhando as três lacunas descritas acima: • Diminua a lacuna de tempo: um desenvolvedor pode escrever código e ter o deploy feito em horas ou até mesmo minutos depois. • Diminua a lacuna de pessoal: desenvolvedores que escrevem código estão proximamente envolvidos em realizar o deploy e acompanhar seu comportamento em produção. • Diminua a lacuna de ferramentas: mantenha desenvolvimento e produção o mais similares possível. 18
  19. 19. Fatores de Gerenciamento 19
  20. 20. Logs • Um log é um stream de eventos sequenciais produzidos por uma aplicação em execução • Um log não tem início, nem fim, mas é contínuo enquanto a aplicação estiver rodando • A aplicação não deveria se preocupar em armazenar o log • Os logs podem ser vistos no terminal • Um serviço externo deve ser configurado para coletar os logs e armazená-los em um local centralizado Trate logs como fluxo contínuo de eventos Tradicionalmente as aplicações salvam os logs em algum arquivo de output, e isso traz a preocupação com armazenamento e gerenciamento de logs. Na metodologia 12 fatores, os logs são tratados como um fluxo contínuo de eventos sem começo ou fim, disponível no terminal, e outras aplicações são responsáveis por coletá-los e armazená-los. 20
  21. 21. Admin Processes • Tarefas administrativas devem fazer parte do deploy da aplicação que estão relacionadas • Exemplos: scripts de migração, monitoramento ou correções de ambiente Execute tarefas de administração/gestão como processos pontuais Algumas aplicações possuem tarefas administrativas, como migração de modelo de banco de dados ou inspeção de ambiente. Esse tipo de tarefa é tratada como parte da aplicação, desde a base de código até a construção e entrega. Um operador não terá que fazer alterações no ambiente de execução da aplicação para executá-las porque elas já estarão prontas e disponíveis no ambiente. 21
  22. 22. Próximos passos 22
  23. 23. Próximos passos • Os 12 fatores tem um objetivo claro, envolvendo portabilidade e escalabilidade • Podem ser utilizados como uma Checklist para o desenvolvimento e deploy de aplicações • Por mais que não envolva padrões de qualidade de códido, não significa que esse assunto deva ser ignorado • A metodologia pode ser estendida para contemplar outros fatores que o time julgue necessário Telemetria Segurança Padrões de qualidade O que mais? 23
  24. 24. Excelência técnica para acelerar sua jornada digital. w w w . l a m b d a 3 . c o m . b r 24

×