Construindo Microsserviços a partir de um Monolito

Talk do Marcos Felipe que rolou na Lecom.

Transcript

1. Construindo microsserviços a partir de um monolito
2. */omarkdev 2
3. 3 Aviso: Um monte de explicação
4. O que é monolito? 4
5. “ Monumento ou obra constituída por um só bloco de pedra. Segundo o google
6. “ Aplicação constituída como uma unidade lógica executável. No mundo de software
8. O que é microsserviço? 8
9. “ Microsserviço é quando separamos cada responsabilidade da aplicação em um serviço. Algumas dizem que é isso
11. “ Microsserviço é uma abordagem para desenvolver uma aplicação como uma suíte de serviços, cada um rodando em seu próprio processo e se comunicando através de mecanismos leves. Estes serviços são construídos em torno de recursos de negócio e publicados em produção de maneira independente através de processos de deploys automatizados. Existe um gerenciamento centralizado mínimo destes serviços, que podem ser escritos em diferentes linguagens e usarem diferentes tecnologias para armazenamento de dados.
12. Características ◉ Dividido por recursos de négocio; ◉ Independentes; ◉ Produtos e não projetos; ◉ Governança descentralizada; ◉ Gerenciamento de dados descentralizados; ◉ Automatização de infra-estrutura; ◉ Design para falhas; ◉ Design evolucionário. 12
13. Se comparamos com um monolito 13
15. “Entendi como a arquitetura de microsserviços funciona, mas quais realmente são as vantagens que eu terei?” ?
16. Vantagens ◉ Escalabilidade; ◉ Melhor utilização dos recursos; ◉ Facilidade de implantação; ◉ Diversidade tecnológica; ◉ Equipes focadas em serviços específicos; ◉ Isolamento de falhas. 16
17. “Mas também tem desvantagens, certo?” ?
18. Desvantagens ◉ Desenvolvimento trabalhoso; ◉ Complexidade operacional; ◉ Chamadas remotas podem ser lentas; ◉ Duplicidade de dados; ◉ Necessidade de uma cultura DevOps forte; ◉ Inimigo do MVP. 18
19. “Interessante, então já posso sair migrando tudo para microsserviços?” ?
20. A sua aplicação tem que estar bem arrumada para isso !
22. Requisitos ◉ Equipe madura; ◉ Processo maduro para implantação; ◉ Familiaridade com o negócio da aplicação; ◉ Cultura DevOps; ◉ Monitoramento básico; ◉ Rápido provisionamento; ◉ Possibilidade de deploy automatizados; ◉ Estar pronto para perder produtividade agora e ganhar futuramente. 22
24. Mas o mais importante, pergunte-se se você realmente precisa de uma arquitetura de microsserviços !
25. “Mas como eu sei se preciso?” ?
26. Necessidades 1. Alguma parte precisa ser deployada e gerenciada de forma independente? 2. Alguma parte precisa de uma escalabilidade ou tecnologia diferente das demais? 3. As partes representam diferentes casos de negócio ou domínio? 4. As abordagens de arquitetura distribuída não resolvem o meu problema? 26
27. Como construir microsserviços a partir de um monolito? 27
31. Podemos fazer algumas coisas antes para facilitar a nossa migração !
32. Pare de cavar O buraco que é seu monolito não pode ficar maior. 1 32
33. “ Se você se encontrar em um buraco, pare de cavar Law of Holes
35. Separe seu front-end do back-end Pode facilitar entender as responsabilidades 2 35
36. Camadas ◉ Presentation layer; ◉ Business logic layer; ◉ Data-access layer. 36
37. Existe uma separação muito clara entre a lógica de apresentação em um lado e as regras de negócio e de dados em outro !
40. Um problema grande quebrado em 2, torna-se 2 problemas menores, mas ainda são problemas. !
41. “Mas como decompor algo já existente?” ?
42. Padrões para nos ajudar ◉ Decompose by business capability; ◉ Decompose by subdomain. 42
43. Decompose by business capability 1 43
44. Decompor em serviços o que são capacidades de negócio. !
45. “ Capacidades de negócio são o que uma empresa faz ou pode fazer. Capacidade de negócio
46. Capacidades de negócio ◉ Filmes; ◉ Celebridades; ◉ Classificação e Comentários; ◉ Eventos; ◉ Notícias; ◉ Trailers; ◉ Usuários; ◉ Anúncios. 46
48. Decompose by subdomain 2 48
49. Cria os serviços que são subdomínios definidos com DDD. !
50. “ Um subdomínio é uma parte específica do domínio, na qual alguns usuários usam um determinado idioma ubíquo. Capacidade de negócio
51. Subdomínios ◉ Filmes: informações, classificação e comentários; ◉ Celebridades: informações classificação e comentários; ◉ Anúncios no site; ◉ Propaganda direcionada; ◉ Blog; ◉ Usuário. 51
53. “Agora ficou fácil, já sei como fica a decomposição, é só começar a desenvolver, certo?” ?
55. Requisitos ◉ Notícias no blog deve mostrar algumas informações sobre os filmes; ◉ Filmes devem mostrar títulos e links de notícias relacionadas. ◉ As informações apresentadas em um serviço sobre o outro serviço pode ser customizada. 55
56. “Mas aí fica fácil, basta eles conectarem no mesmo banco”
57. O ideal é confirmar se sua abordagem está seguindo as características de microsserviço !
58. Características ◉ Dividido por recursos de négocio; ◉ Independentes; ◉ Produtos e não projetos; ◉ Governança descentralizada; ◉ Gerenciamento de dados descentralizados; ◉ Automatização de infra-estrutura; ◉ Design para falhas; ◉ Design evolucionário. 58
59. Alguns efeitos colaterais de se fazer desta maneira !
60. Efeitos colaterais ◉ Se uma query de um serviço travar o banco de dados, o outro serviço é afetado; ◉ Ninguém garante que um serviço não vai alterar o dado do outro serviço; ◉ A escalabilidade afeta todos os serviços. 60
61. “Mas achei a solução, cada um com seu banco de dados e eles se comunicam por uma API”
62. Sempre confirmar as características !
63. Características ◉ Dividido por recursos de négocio; ◉ Independentes; ◉ Produtos e não projetos; ◉ Governança descentralizada; ◉ Gerenciamento de dados descentralizados; ◉ Automatização de infra-estrutura; ◉ Design para falhas; ◉ Design evolucionário. 63
64. Outros efeitos colaterais de se fazer desta maneira !
65. Efeitos colaterais ◉ Se um serviço cair o outro poderá não continuar funcionando normalmente; ◉ Se houver uma mudança em um serviço o outro é afetado. 65
66. “Ficou mais difícil, mas os serviços podem se comunicar por eventos.”
67. Confirmar as características sempre! !
68. Características ◉ Dividido por recursos de négocio; ◉ Independentes; ◉ Produtos e não projetos; ◉ Governança descentralizada; ◉ Gerenciamento de dados descentralizados; ◉ Automatização de infra-estrutura; ◉ Design para falhas; ◉ Design evolucionário. 68
69. Parece que conseguimos! !
70. Mas... !
71. Você não tem garantia que os dados vão ficar consistentes !
73. Manipulação de dados é um problema em microsserviços, talvez o problema mais difícil !
74. Padrões para resolver problemas de manipulação de dados ◉ Databases per Service; ◉ Shared Database; ◉ Saga; ◉ API Composition; ◉ CQRS; ◉ Domain event; ◉ Event sourcing. 74
75. A manipulação e os limites dos dados devem estar alinhados com o seu negócio. !
76. Toda escolha vai ter um efeito colateral, o ideal é minimizar isso. !
77. “Ok, acredito que a manipulação dos meus dados está bem desenvolvida e limitada, mas como meus serviços vão se comunicar?” ?
79. Esse tipo de problema se chama Service Discovery !
80. Padrões para resolver problemas de service discovery ◉ Client-side discovery; ◉ Server-side discovery; ◉ Service registry; ◉ Self registration; ◉ 3rd party registration. 80
82. Cada padrão tem um propósito e uma complexidade !
83. “Eu posso começar com microsserviços?” ?
84. Monolito - Se você é capaz de criar um bom monolito, talvez seja capaz de criar bons microsserviços; - Refatorar algo que é pequeno é mais fácil; - Ao começar com monolito é provável que as partes fiquem muito acopladas. Microsserviços - É difícil testar ideias de forma rápida; - Não consegue priorizar velocidade; - Dificuldade em definir limites de serviços no começo
85. Monolito não é ruim. !
86. Microsserviço não é bala de prata. !
87. Escolha com sabedoria. !