Transferir como PDF, PPTX
Carregado porWellington Silva
Do monolito aos microserviços com Docker (PHPSP+IMA)
O documento discute o processo de transição de um monólito para uma arquitetura de microserviços utilizando Docker, destacando a importância de ciclos de feedback e práticas como integração contínua. A evolução do design de software é abordada, enfatizando que microserviços não escalam apenas software, mas também equipes, além de capturar os desafios e soluções associadas à complexidade crescente. Ferramentas e estratégias, incluindo o uso de APIs e automação de pipelines, são sugeridas para facilitar essa transição.
Do monolito aos microserviços com Docker (PHPSP+IMA)
- 1. Escalando uma AplicaçãoPHP com Docker Do monolito ao microserviço
- 2. $ whoami Wellington F.Silva Técnico Telecom, Programador, Devops, Instrutor, Escritor, Marido, Pai, Apreciador de cafés e viciado em pizza. AKA: wsilva | tom | boina | fisi
- 3. Agenda • Monolito • Ciclode feedback • Evolução do Monolito • Jornada ao microserviço • Docker • Demo
- 4.
- 5.
- 6.
- 7. Monolith First • http://martinfowler.com/bliki/ MonolithFirst.html •Começa rápido • Baixa complexidade entre desenvolvimento e a entrega
- 8. Monolith First • http://martinfowler.com/bliki/ MonolithFirst.html •Começa rápido • Baixa complexidade entre desenvolvimento e a entrega • Baixo Custo
- 9. Monolith First • http://martinfowler.com/bliki/ MonolithFirst.html •Começa rápido • Baixa complexidade entre desenvolvimento e a entrega • Baixo Custo • Meta: MVP
- 10.
- 11. Feedback Loop • PDCA- Plan, Do, Check, Act
- 12. Feedback Loop • PDCA- Plan, Do, Check, Act • Retomada de contexto é custosa
- 13. Feedback Loop • PDCA- Plan, Do, Check, Act • Retomada de contexto é custosa • Testes diminuem o tempo de feedback loop
- 14. Feedback Loop • PDCA- Plan, Do, Check, Act • Retomada de contexto é custosa • Testes diminuem o tempo de feedback loop • Continuous Integration e Continuous Deployment / Delivery
- 15. Feedback Loop • PDCA- Plan, Do, Check, Act • Retomada de contexto é custosa • Testes diminuem o tempo de feedback loop • Continuous Integration e Continuous Deployment / Delivery • Muitos bugs - falta de confiança para colocar em produção
- 16. –Conway’s Law “Organizations whichdesign systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
- 17.
- 18. Big Monolith • Aumentodo sistema, mais pessoas para mantê-lo
- 19. Big Monolith • Aumentodo sistema, mais pessoas para mantê-lo • The Mythical Man-Month do Frederick Brooks: "Adding manpower to a late software project makes it later"
- 20. Big Monolith • Aumentodo sistema, mais pessoas para mantê-lo • The Mythical Man-Month do Frederick Brooks: "Adding manpower to a late software project makes it later” • 2 pizza team - tamanho dos times - Jeff Bezos da AWS
- 21. Big Monolith • Aumentodo sistema, mais pessoas para mantê-lo • The Mythical Man-Month do Frederick Brooks: "Adding manpower to a late software project makes it later” • 2 pizza team - tamanho dos times - Jeff Bezos da AWS • O crescimento leva naturalmente na divisão de equipes
- 22. –Desconhecido “Softwares são desenvolvidospor pessoas e para pessoas.”
- 23.
- 24. Microservice Journey • Microservicenão escala software, escala pessoas
- 25. Microservice Journey • Microservicenão escala software, escala pessoas • Art of Scalability - Arquitetos do Ebay - 3 dimensões escaláveis:
- 26. Microservice Journey • Microservicenão escala software, escala pessoas • Art of scalability - Arquitetos do Ebay - 3 dimensões escaláveis: • horizontal: mais máquinas
- 27. Microservice Journey • Microservicenão escala software, escala pessoas • Art of scalability - Arquitetos do Ebay - 3 dimensões escaláveis: • horizontal: mais máquinas • particionamento de dados: dividindo coisas similares
- 28. Microservice Journey • Microservicenão escala software, escala pessoas • Art of scalability - Arquitetos do Ebay - 3 dimensões escaláveis: • horizontal: mais máquinas • particionamento de dados: dividindo coisas similares • decomposição funcional: dividir responsabilidades diferentes
- 29. Microservice Journey • Microservicediminui o contexto, permite serviço coeso, baixo acoplamento
- 30. Microservice Journey • Microservicediminui o contexto, permite serviço coeso, baixo acoplamento • APIs para comunicação entre serviços distintos
- 31. Microservice Journey • Microservicediminui o contexto, permite serviço coeso, baixo acoplamento • APIs para comunicação entre serviços distintos • Permite utilizar as melhores tecnologias (liguagem, stack) para resolver cada problema
- 32.
- 33. Microservice Journey • Problemasnovos • aumento de complexidade
- 34. Microservice Journey • Problemasnovos • aumento de complexidade • confiabilidade tem que estar no software (hardware falha)
- 35. Microservice Journey • Problemasnovos • aumento de complexidade • confiabilidade tem que estar no software (hardware falha) • sempre previnir falhas (de comunicação, rede)
- 36. Microservice Journey • Problemasnovos • aumento de complexidade • confiabilidade tem que estar no software (hardware falha) • sempre previnir falhas (de comunicação, rede) • diversos pipelines de entrega (CI/CD) que se interdependem
- 37. Microservice Journey • Problemasnovos • smart router - testes AB, deploys blue-green, cannary releases
- 38. Microservice Journey • Problemasnovos • smart router - testes AB, deploys blue-green, cannary releases • log unificado das instâncias
- 39. Microservice Journey • Problemasnovos • smart router - testes AB, deploys blue-green, cannary releases • log unificado das instâncias • dashboard central com status de todos os serviços
- 40. Microservice Journey • Problemasnovos • smart router - testes AB, deploys blue-green, cannary releases • log unificado das instâncias • dashboard central com status de todos os serviços • monitoria e alarmes para cada serviço
- 41. Microservice Journey • Problemasnovos • smart router - testes AB, deploys blue-green, cannary releases • log unificado das instâncias • dashboard central com status de todos os serviços • monitoria e alarmes para cada serviço • testes integrados mais difíceis de realizar
- 42.
- 43. Microservice Journey • Estratégia •funções e serviços satélites
- 44. Microservice Journey • Estratégia •funções e serviços satélites • achar os limites do contexto da aplicação - se foi usado DDD fica mais fácil identificar
- 45. Microservice Journey • Estratégia •funções e serviços satélites • achar os limites do contexto da aplicação - se foi usado DDD fica mais fácil identificar • automatização de pipeline (devops)
- 46. Microservice Journey • Estratégia •funções e serviços satélites • achar os limites do contexto da aplicação - se foi usado DDD fica mais fácil identificar • automatização de pipeline (devops) • utilizar APIs, pontos de comunicação síncronos e assíncronos
- 47.
- 48. Microservice Journey • Estratégia •CQRS • consistência eventual de dados
- 49. Microservice Journey • Estratégia •CQRS • consistência eventual de dados • aplicar o 12 factor apps para a criação dos novos serviços
- 50. Microservice Journey • Estratégia •CQRS • consistência eventual de dados • aplicar o 12 factor apps para a criação dos novos serviços • fazer um balanço de qual projeto geram mais valor e dão menos trabalho (geralmente 1 ou 2 semanas)
- 51. Microservice Journey • Estratégia •CQRS • consistência eventual de dados • aplicar o 12 factor apps para a criação dos novos serviços • fazer um balanço de qual projeto geram mais valor e dão menos trabalho (geralmente 1 ou 2 semanas) • com a evolução matamos o monólito por inanição
- 52. Microservice Journey • Estratégia •utilizar a última geração de Paas, containers
- 54. Docker • Evolução doLXC (Linux Containers)
- 55. Docker • Evolução doLXC (Linux Containers) • Muito rápido (trabalha com processos)
- 56. Docker • Evolução doLXC (Linux Containers) • Muito rápido (trabalha com processos) • Muito leve (não precisa do Kernel no Guest)
- 57. Docker • Evolução doLXC (Linux Containers) • Muito rápido (trabalha com processos) • Muito leve (não precisa do Kernel no Guest) • Open Source
- 58. Docker • Diversas Ferramentaspara cluster e orquestração
- 59. Docker • Diversas Ferramentaspara cluster e orquestração • Melhora a distribuição de recursos
- 60.
- 61.
- 62.
- 63.
- 64.
- 65. –Wellington F. Silva “Docker.Perfeito pra microservice”
- 66.
- 67.