Construindo Aplicações PHP com TWELVE-FACTOR APP
•Transferir como ODP, PDF•
1 gostou•335 visualizações
I. O documento discute os princípios do Twelve-Factor App para construção de aplicações SaaS escaláveis e portáveis. II. Doze princípios são apresentados, incluindo código versionado, dependências declaradas, configurações como variáveis de ambiente e logs como fluxos de eventos. III. Seguindo esses princípios, aplicações podem ser desenvolvidas para fácil implantação contínua e escalabilidade.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Construindo Aplicações PHP com TWELVE-FACTOR APP
Semelhante a Construindo Aplicações PHP com TWELVE-FACTOR APP (20)
Construindo Aplicações PHP com TWELVE-FACTOR APP
- 1. Construindo Aplicações PHP com TWELVE-FACTOR APP Marcela Godoy 06 de Março de 2018
- 2. #MeuLugarEmTI Marcela Godoy Backend Developer @Eduzz Coorganizadora Meetup @PHPSP - Campinas @magodoy88 helloworld@marcelagodoy.net
- 4. Maior foco no negócio Escalabilidade para demandas crescentes Usuário final sem preocupação com infraestrutura Utilizado em qualquer lugar e em diferentes plataformas Cloud Computing
- 5. SaaS Software as a Service (Software como Serviço)
- 7. Fácil de implementar gradualmente Aplicação sempre atualizada, compatível e segura O provedor cuida de tudo Acesso de qualquer lugar em diferentes plataformas SaaS
- 8. 600 Startups brasileiras Possuem ao menos um produto SaaS SaaS
- 9. Eficiente Sustentável Padrões de desenvolvimento Facilite o trabalho do time Como construir uma aplicação SaaS?
- 10. Adam Wiggins + Heroku Team The Twelve-Factor App
- 11. The Twelve-Factor App Facilitar a dinâmica entre desenvolvedores Resolver problemas sistêmicos Boas práticas Escalabilidade Portabilidade
- 12. The Twelve-Factor App Refactoring Improving the Design of Existing Code (Martin Fowler - 1999) Patterns of Enterprise Application Architecture (Martin Fowler - 2003)
- 14. I. Base de Código “Uma base de código rastreada por controle de versão. Muitos deploys.”
- 15. Controle de Versão (GIT, Mercurial, Subversion) Repositório (Base de código) I. Base de Código
- 16. Relação de um-para-um: I. Base de CódigoI. Base de Código Uma base de código = Uma aplicação Vários deploys para a mesma base de código
- 17. I. Base de Código Várias bases de código envolvidas = Sistema distribuído Várias aplicações na mesma base = Errado!
- 18. I. Base de Código + +
- 19. II. Dependências “Declare e isole explicitamente as dependências.”
- 20. Gerenciador de dependências II. Dependências Dependências declaradas e isoladas Manifesto de declaração Dependências declaradas e isoladas Ferramenta de isolamento
- 21. Declaração e isolamento de dependência sempre juntos II. Dependências Recursos do Sistema devem ser vendorizados
- 23. II. Dependências
- 24. II. Dependências vendor/autoload.php $ composer install $ composer update
- 25. III. Configurações “Armazene as configurações no ambiente.”
- 26. Configuração: Tudo que é provável variar entre deploys III. Configurações Constantes no código = muito trabalho!
- 27. Armazenar as configurações em um arquivo de variáveis de ambiente III. Configurações Novo deploy sem alterar a base de código
- 28. Estou fazendo isso certo? III. Configurações “Minha base de código poderia ser um repositório público sem comprometer a minha segurança?”
- 34. IV. Serviços de Apoio “Trate serviços de apoio como recursos anexados.”
- 35. Qualquer serviço que a aplicação consuma como parte de sua operação (Gerenciamento de dados, cache, filas) IV. Serviços de Apoio Serviço de apoio Recurso Configurações
- 36. Facilidade para acoplar e desacoplar recursos da aplicação IV. Serviços de Apoio
- 37. Sabe como? IV. Serviços de Apoio
- 38. IV. Serviços de Apoio
- 39. IV. Serviços de Apoio
- 40. V. Build, Release, Run “Separe estritamente os estágios de construção e execução.”
- 41. Para que a base de código se transforme em versão: V. Build, Release, Run Build + Release Run+
- 42. Commit + Dependências = Build V. Build, Release, Run Build + Configurações do Deploy = Release (Não se esqueça do nome da versão!) Release + ambiente de execução + start( ) = Run!
- 43. V. Build, Release, Run Releases nunca voltam ao estágio de Build! Códigos alterados geram novas Releases Ferramentas de Deploy revertem Releases (Rollback!) Novos códigos no Deploy iniciam uma nova Build
- 44. V. Build, Release, Run
- 45. VI. Processos “Execute a aplicação como um ou mais processos que não armazenam estados.”
- 46. Processos de stateless e shared-nothing VI. Processos Dados consistentes devem ser armazenados em serviços de apoio Escalabilidade horizontal
- 47. Memórias e sistemas de arquivos apenas para cache de transição única VI. Processos Sessões persistentes – NÃÃÃÃO! (Use um datastore: memcached, redis...)
- 48. VI. Processos
- 49. VII. Vínculo de Portas “Exporte serviços via vínculo de portas.”
- 50. Aplicação auto-contida VII. Vínculo de Portas Escuta e recebe requisições através de uma porta Um app torna-se serviço de outro vinculando portas
- 51. VII. Vínculo de Portas
- 52. VIII. Concorrência “Escale através do processo modelo.”
- 53. VIII. Concorrência A execução de uma aplicação é representada por processos Arquitete a aplicação para lidar com diferentes cargas
- 54. VIII. Concorrência Performance vs. Custo Escalonamento por meio de paralelização
- 55. IX. Descartabilidade “Maximize robustez com inicialização rápida e desligamento suave.”
- 56. IX. Descartabilidade Processos são descartáveis Escalonamento elástico Deploy rápido Produção robusta
- 57. IX. Descartabilidade Desligamento suave: Porta de serviço Requisições finalizam Desligamento
- 58. IX. Descartabilidade Morte súbita: Falha de hardware Retorna tarefas à fila Ferramenta Backend
- 59. X. Paridade entre Desenvolvimento E Produção “Mantenha o desenvolvimento, homologação e produção os mais similares possível.”
- 60. X. Paridade entre Desenvolvimento e Produção ( 1 ) Tempo: Dev trabalhando no deploy local a muito tempo... ( 2 ) Pessoal: O Dev finalizou o código, mas está esperando o time de deploy ( 3 ) Ferramentas: O Dev utiliza OSX, Nginx e SQLite. Enquanto isso em produção temos Linux, Apache e MySQL
- 61. X. Paridade entre Desenvolvimento e Produção Implantação contínua: “Garante entrega ao usuário final sem gargalo no ambiente de homologação”
- 62. X. Paridade entre Desenvolvimento e Produção ( 1 ) Tempo: Dev escreve o código e realiza o deploy em poucas horas ( 2 ) Pessoal: O Dev finalizou o código, é envolvido com o deploy e acompanha o comportamento em produção ( 3 ) Ferramentas: Mantenha desenvolvimento e produção o mais similar possível!
- 63. X. Paridade entre Desenvolvimento e Produção O desenvolvedor não deve usar ferramentas adaptadoras Deploys com mesmas versões de cada serviço de apoio
- 64. XI. Logs “Trate logs como fluxos de eventos.”
- 65. XI. Logs “Fluxos de eventos agregados e ordenados por tempo, coletados dos fluxos de saída de todos os processos em execução dos serviços de apoio”
- 66. XI. Logs Não escreve ou gera serviços de Log Gerido pelo ambiente de execução
- 67. XI. Logs Captura-se o fluxo de saída; Agrupa-se a outros fluxos; Direciona para um arquivamento de longo prazo
- 68. XI. Logs Elasticseach Logstach Kibana
- 69. XII. Processos Administrativos “Rode tarefas de administração/gestão em processos pontuais.”
- 70. XII. Processos Administrativos Processos Pontuais: Migração de uma base de dados, Execução arbitrária de códigos... Execução em ambiente idêntico a outros processos Utilizar declaração e isolamento de dependências
- 71. E ao final... Estamos prontos para escalar Possuímos uma ótima portabilidade Seguimos boas práticas Temos uma aplicação robusta
- 72. E ao final... Era isso que a gente queria!
- 73. Referências www.12factor.net Beyond the Twelve-Factor App Kevin Hoffman