A adoção de arquitetura baseada em microsserviços sem o conhecimento das suas desvantagens tem sido umas das principais dores de cabeças em diversos projetos de modernização que estamos encontrando no mercado atualmente. Acreditamos que decompor sistemas em serviços sem combater adequadamente o acoplamento aumenta a complexidade e, frequentemente, decisões equivocadas transformam essas aplicações em verdadeiros monolíticos distribuídos.
Um dos principais indícios de que estamos trabalhando em um monolito distribuído é quando uma nova funcionalidade gera um deploy sincronizado de um conjunto de serviços, ao invés de um único serviço impactado pela nova funcionalidade. Essa característica evidencia que o isolamento das aplicações provavelmente não está ocorrendo de maneira adequada e os principais benefícios de uma arquitetura de microsserviços não estão sendo aproveitados.
Este problema geralmente acontece por falta de conhecimento profundo do domínio, onde os microsserviços são segmentados sem levar em consideração a coesão dos contextos propiciando um forte acoplamento entre eles. Contudo, podemos adotar algumas estratégias para mitigar estas dores de cabeça.
Comece simples, comece com um monolito bem feito
Geralmente não é recomendável já iniciar uma arquitetura de maneira muito fragmentada devido ao custo advindo da complexidade. Uma boa estrutura monolítica pode ser muito mais simples de ser mantida. E quando o conhecimento do negócio se tornar mais sólido, faça (se necessário) a separação dos serviços levando em consideração os contextos, a estrutura do time e a necessidade de escala.
Tenha um padrão coerente para segmentar os microsserviços
Definir as fronteiras de cada microsserviço não é tarefa simples, mas é a chave para evitar acoplamentos desnecessários. O Domain Driven Design apresenta o conceito de bounded-context que pode ser útil como diretriz para definir uma estratégia consistente de segmentação dos microsserviços.
Evolua de maneira incremental
É interessante que a segregação dos serviços seja feita de forma gradual. Aumentar a granularidade dos serviços tornando-os “micro” de maneira desnecessária vai apenas aumentar a complexidade e o custo para manter as aplicações.
E não se esqueça…
De forma geral, é melhor ter que, eventualmente, segmentar um serviço do que ter que lidar de maneira desnecessária com uma explosão de serviços e os seus desafios de consistência eventual.
Esse tema é discutido de maneira mais ampla no livro “Monolith to Microservices” que recomendamos, do Sam Newman.
