- "Monolith > apps > services > microservices"
- Primeiro, isso não é uma regra; é apenas a minha opinião. Quem já construiu sistemas distribuídos em larga escala sabe que, na prática, isso não funciona exatamente assim e que é preciso se adaptar
- Segundo, a etapa importa
- Se a empresa tem de 5 a 50 pessoas, simplesmente vá de Monolith
- Se a empresa tem 10 mil pessoas, ela provavelmente terá tudo isso. Mas falando sobre como meu pensamento mudou em relação ao passado...
Primeiro, vamos às definições (Definition)
- monolith - xyz.com
- apps - abc.xyz.com
- services - dão suporte aos apps/monoliths, infraestrutura central, funções centrais de compliance, e podem nem ser escritos pelo time de app (podem ser mantidos pela infraestrutura)
- microserivces - algumas centenas de linhas de código, em sua maioria pontuais, poderiam/deveriam ser uma biblioteca ou SDK
Why? : basicamente por causa de "Speed & Risk"
- #1 É mais fácil para todo o time de desenvolvimento trabalhar em um único app grande (imagine que o site inteiro seja um app em Rails)
- #2 À medida que você cresce, o sistema distribuído que inevitavelmente vai surgir já é difícil de raciocinar por si só, mesmo sem centenas de microservices inerentemente arriscados
- #3 Se você for totalmente para o micro, terá de introduzir novos conceitos para lidar com a proliferação descontrolada
- #4 Serviços de infraestrutura sob medida (Bespoke) ou microservices são a forma extrema de dívida. Código já é dívida, mas um serviço é a versão extrema disso. Pense no que isso significa. Faça com que isso vire um ponto de alavancagem
- Engenheiros de sistemas distribuídos odeiam duplicação, então se algo está sendo feito em vários lugares, pensam: "vamos extrair isso e criar um microservice"
- Em teoria isso faz sentido, e até dez ou vinte deles tudo bem. Mas quando passa de dezenas ou começa a ser usado em uma empresa grande, deixa de ser um problema técnico e passa a ser um problema organizacional
- O que estou dizendo pode soar como uma falsa dicotomia, mas na prática existem desafios técnicos com microservices e ainda mais problemas organizacionais
O que me preocupa
- #1 (A menos que a empresa seja liderada, de forma incomum, por um CEO com origem em TI) infraestrutura sempre acaba ficando em segundo plano nas prioridades
- #2 Quando há serviços demais, normalmente surgem problemas de ownership e de definição de fronteiras
- #3 Para lidar com inúmeros microservices, introduz-se ainda mais ferramentas
- #4 O mais importante: cada microservice que deveria ter sido uma biblioteca ou SDK introduz risco em produção
O que eu geralmente recomendo
- #1 Mantenha o Monolith pelo maior tempo possível
- #2 Comece os services pelo que a infraestrutura precisa, não pelo lado do desenvolvimento de app
- #3 Se precisar quebrar o Mono, decomponha em apps grandes, não em serviços pequenos
- #4 Pense em cada novo app como uma parede virtual dentro da empresa
- #5 Sempre que possível, prefira bibliotecas a microservices
13 comentários
A parte final, com as preocupações e recomendações, realmente gera identificação. Na prática, tanto o porte da empresa quanto o do serviço seguem uma lógica parecida, e tive a sensação de que será preciso um excelente discernimento para se preparar com antecedência para o momento em que dividir as coisas se tornar inevitável.
Não deveria depender do tamanho do sistema, e não do tamanho da empresa? Será que eu estava entendendo MSA errado?
Entre os comentários acima,
concordo, em princípio, com a opinião de que
não seria o problema dos microsserviços em si, mas sim a expansão indiscriminada dos serviços?
À medida que a empresa cresce, as desvantagens do próprio monólito — como problemas de deploy e gerenciamento de branches — ficam claras demais, então parece que é preciso escolher bem o trade-off entre custo e produtividade.
Texto muito bom. Obrigado.
Parece algo parecido com a polêmica sobre a importância dos padrões de design, não é?
Padrões de design são padrões de código que surgiram no processo de resolver diversos problemas...
No fim das contas, eles devem ser adaptados e aplicados conforme a situação e a necessidade...
Mas às vezes tem gente que trata padrão de design como se fosse resposta modelo, algo obrigatório, e fica obcecada com isso...
Hoje em dia, com MSA, parece acontecer algo parecido: está aumentando o número de pessoas que acham que tem que ser MSA a qualquer custo.
Parece aquela discussão de ovo ou galinha primeiro.
O problema não é dos microsserviços, e sim a expansão desenfreada dos serviços, não?
Acho que é importante ter um equilíbrio adequado.
Quando se vai para microserviços, por haver o risco de que novo recurso = novo microserviço,
não será que isso vai ficando cada vez mais difícil de gerenciar?
Isso me lembra um texto chamado 'Goodbye Microservices', que foi publicado anteriormente no blog técnico da Segment.
A Segment também é uma CDP e, apesar de processar uma quantidade enorme de dados em tempo real, migrou de uma arquitetura de Microservices para um Monolith e organizou no blog os motivos para isso. Acho que, em certa medida, isso também se conecta com este texto :)
https://segment.com/blog/goodbye-microservices/
No geral, isso bate com o que eu penso.
Na nossa empresa, temos 5 desenvolvedores, então acho que, por enquanto, faz sentido continuar seguindo um monólito (Ruby on Rails).
Se virar um projeto em que mais de 50 pessoas desenvolvem ao mesmo tempo, como no texto acima, acho que aí vamos acabar desenvolvendo um segundo monólito.
Se a empresa tiver de 5 a 50 pessoas, simplesmente vá de Monolith << isso se refere ao total de integrantes, não ao número de desenvolvedores, certo?
Acho que ele está falando do tamanho da empresa~
Se possível, manter o monólito pelo maior tempo possível < concordo demais com isso. Ao separar, o aumento do custo de manutenção pesa bastante.
Parece um texto como reação ao fato de MSA estar virando um dogma, e nesse sentido acho que tem seu valor.