Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Do monolito aos microserviços com Docker (PHPS...

Do monolito aos microserviços com Docker (PHPSP+IMA)

Palestra ministrada no PHPSP+IMA em Campinas-SP em 20/08/2016. Abordamos como sair do monolito e ir para o microserviço conforme sua aplicação cresce e simulamos isso com containers Docker

Wellington F. Silva

August 20, 2016
Tweet

More Decks by Wellington F. Silva

Other Decks in Technology

Transcript

  1. $ 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
  2. Agenda • Monolito • Ciclo de feedback • Evolução do

    Monolito • Jornada ao microserviço • Docker • Demo
  3. Monolith First • http://martinfowler.com/bliki/ MonolithFirst.html • Começa rápido • Baixa

    complexidade entre desenvolvimento e a entrega • Baixo Custo • Meta: MVP
  4. Feedback Loop • PDCA - Plan, Do, Check, Act •

    Retomada de contexto é custosa
  5. Feedback Loop • PDCA - Plan, Do, Check, Act •

    Retomada de contexto é custosa • Testes diminuem o tempo de feedback loop
  6. Feedback Loop • PDCA - Plan, Do, Check, Act •

    Retomada de contexto é custosa • Testes diminuem o tempo de feedback loop • Continuous Integration e Continuous Deployment / Delivery
  7. 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
  8. –Conway’s Law “Organizations which design systems ... are constrained to

    produce designs which are copies of the communication structures of these organizations”
  9. Big Monolith • Aumento do sistema, mais pessoas para mantê-lo

    • The Mythical Man-Month do Frederick Brooks: "Adding manpower to a late software project makes it later"
  10. Big Monolith • Aumento do 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
  11. Big Monolith • Aumento do 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
  12. Microservice Journey • Microservice não escala software, escala pessoas •

    Art of Scalability - Arquitetos do Ebay - 3 dimensões escaláveis:
  13. Microservice Journey • Microservice não escala software, escala pessoas •

    Art of scalability - Arquitetos do Ebay - 3 dimensões escaláveis: • horizontal: mais máquinas
  14. Microservice Journey • Microservice nã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
  15. Microservice Journey • Microservice nã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
  16. Microservice Journey • Microservice diminui o contexto, permite serviço coeso,

    baixo acoplamento • APIs para comunicação entre serviços distintos
  17. Microservice Journey • Microservice diminui 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
  18. Microservice Journey • Problemas novos • aumento de complexidade •

    confiabilidade tem que estar no software (hardware falha)
  19. Microservice Journey • Problemas novos • aumento de complexidade •

    confiabilidade tem que estar no software (hardware falha) • sempre previnir falhas (de comunicação, rede)
  20. Microservice Journey • Problemas novos • 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
  21. Microservice Journey • Problemas novos • smart router - testes

    AB, deploys blue-green, cannary releases • log unificado das instâncias
  22. Microservice Journey • Problemas novos • smart router - testes

    AB, deploys blue-green, cannary releases • log unificado das instâncias • dashboard central com status de todos os serviços
  23. Microservice Journey • Problemas novos • 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
  24. Microservice Journey • Problemas novos • 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
  25. 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
  26. 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)
  27. 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
  28. Microservice Journey • Estratégia • CQRS • consistência eventual de

    dados • aplicar o 12 factor apps para a criação dos novos serviços
  29. 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)
  30. 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
  31. Docker • Evolução do LXC (Linux Containers) • Muito rápido

    (trabalha com processos) • Muito leve (não precisa do Kernel no Guest)
  32. Docker • Evolução do LXC (Linux Containers) • Muito rápido

    (trabalha com processos) • Muito leve (não precisa do Kernel no Guest) • Open Source