Baixar para ler offline
Carregado porMarcela Godoy Cruz
Construindo Aplicações PHP com Twelve-Factor App
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.
![[ServerlessDaysSP - 2024.10.19] Descomplicando 12-Factor Apps com Serverless ...](https://cdn.slidesharecdn.com/ss_thumbnails/serverlessdayssp-2024-241021195342-b53b4354-thumbnail.jpg?width=640&height=640&fit=bounds)
Construindo Aplicações PHP com Twelve-Factor App
- 1. Construindo Aplicações PHPcom 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
- 3.
- 4. Maior foco nonegó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 aService (Software como Serviço)
- 6.
- 7. Fácil de implementargradualmente 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 Possuemao menos um produto SaaS SaaS
- 9. Eficiente Sustentável Padrões de desenvolvimento Faciliteo trabalho do time Como construir uma aplicação SaaS?
- 10. Adam Wiggins + Heroku Team TheTwelve-Factor App
- 11. The Twelve-Factor App Facilitara dinâmica entre desenvolvedores Resolver problemas sistêmicos Boas práticas Escalabilidade Portabilidade
- 12. The Twelve-Factor App Refactoring Improvingthe Design of Existing Code (Martin Fowler - 1999) Patterns of Enterprise Application Architecture (Martin Fowler - 2003)
- 13.
- 14. I. Base deCó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 deCódigo Várias bases de código envolvidas = Sistema distribuído Várias aplicações na mesma base = Errado!
- 18. I. Base deCódigo + +
- 19. II. Dependências “Declare eisole 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 isolamentode dependência sempre juntos II. Dependências Recursos do Sistema devem ser vendorizados
- 22.
- 23.
- 24. II. Dependências vendor/autoload.php $ composerinstall $ composer update
- 25. III. Configurações “Armazene asconfiguraçõ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çõesem um arquivo de variáveis de ambiente III. Configurações Novo deploy sem alterar a base de código
- 28. Estou fazendo issocerto? III. Configurações “Minha base de código poderia ser um repositório público sem comprometer a minha segurança?”
- 29.
- 30.
- 31.
- 32.
- 33.
- 34. IV. Serviços deApoio “Trate serviços de apoio como recursos anexados.”
- 35. Qualquer serviço quea 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 acoplare desacoplar recursos da aplicação IV. Serviços de Apoio
- 37. Sabe como? IV. Serviçosde Apoio
- 38. IV. Serviços deApoio
- 39. IV. Serviços deApoio
- 40. V. Build, Release,Run “Separe estritamente os estágios de construção e execução.”
- 41. Para que abase 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.
- 45. VI. Processos “Execute aaplicação como um ou mais processos que não armazenam estados.”
- 46. Processos de statelesse shared-nothing VI. Processos Dados consistentes devem ser armazenados em serviços de apoio Escalabilidade horizontal
- 47. Memórias e sistemasde arquivos apenas para cache de transição única VI. Processos Sessões persistentes – NÃÃÃÃO! (Use um datastore: memcached, redis...)
- 48.
- 49. VII. Vínculo dePortas “Exporte serviços via vínculo de portas.”
- 50. Aplicação auto-contida VII. Vínculode 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 dePortas
- 52. VIII. Concorrência “Escale atravésdo processo modelo.”
- 53. VIII. Concorrência A execuçãode 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 robustezcom inicialização rápida e desligamento suave.”
- 56. IX. Descartabilidade Processos sãodescartáveis Escalonamento elástico Deploy rápido Produção robusta
- 57. IX. Descartabilidade Desligamento suave: Portade serviço Requisições finalizam Desligamento
- 58. IX. Descartabilidade Morte súbita: Falhade hardware Retorna tarefas à fila Ferramenta Backend
- 59. X. Paridade entreDesenvolvimento E Produção “Mantenha o desenvolvimento, homologação e produção os mais similares possível.”
- 60. X. Paridade entreDesenvolvimento 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 entreDesenvolvimento e Produção Implantação contínua: “Garante entrega ao usuário final sem gargalo no ambiente de homologação”
- 62. X. Paridade entreDesenvolvimento 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 entreDesenvolvimento 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 logscomo fluxos de eventos.”
- 65. XI. Logs “Fluxos deeventos 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 escreveou gera serviços de Log Gerido pelo ambiente de execução
- 67. XI. Logs Captura-se ofluxo de saída; Agrupa-se a outros fluxos; Direciona para um arquivamento de longo prazo
- 68.
- 69. XII. Processos Administrativos “Rodetarefas de administração/gestão em processos pontuais.”
- 70. XII. Processos Administrativos ProcessosPontuais: 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... Estamosprontos para escalar Possuímos uma ótima portabilidade Seguimos boas práticas Temos uma aplicação robusta
- 72. E ao final... Eraisso que a gente queria!
- 73. Referências www.12factor.net Beyond theTwelve-Factor App Kevin Hoffman
- 74.