Skip to content

O tema Micro-Serviços é igual sexo na adolescência, todos falam com autoridade e ao mesmo tempo a maioria tem dúvida.

Hoje em qualquer equipe de desenvolvimento quando se vai criar algo novo já se fala em criar em micro-serviços. Quando estamos em um legado o tema também é falado. Afinal, será que temos real conhecimento para criar micro-serviços? Seria o melhor para o nosso contexto?

O título desse post foi retirado de Dino Esposito, segundo Elemar Júnior, e acredito ser uma das maiores verdades sobre o tema. A definição de micro-serviços é simples segundo o site microservices.io:

“É um estilo arquitetural que estrutura uma aplicação como uma coleção de serviços que são:

  • Altamente manutenível e testado
  • Baixo acoplamento
  • Deploy de forma independente
  • Propriedade de uma equipe pequena
  • Organizado em torno dos recursos do negócio”

Para mim o maior problema de entendimento é com o ultimo item, mas isso eu explico depois.

Na teoria, qualquer DEV com meia experiência de vida já consegue fazer um micro-serviço e entrar para um seleto grupo hypster, atualizar seu CV e falar: “eu entendo do assunto”.

O problema vem depois e ai a dor de cabeça aumenta. Em um dos meus estudos sobre o tema, um palestrante falou uma coisa que achei certíssima, O problema de micro-serviço é a palavra “micro”. O que ele quis dizer? Que quando lemos isso, logo pensamos que nosso serviço tem que ser muito pequeno e tão pequeno que vira um problema para os outros serviços ao ponto de ficarmos acoplado.

Isso acontece por que estudamos o assunto de forma literal e não fazemos um estudo mais aprofundado quando alguns altores falam “Organizado em torno dos recursos do negócio”

Recentemente em um projeto que estou vimos que fomos afetados pela falta de conhecimento e surfarmos na onda, criamos dois serviços que no final deveriam ser apenas um. E como sabemos disso? O acoplamento está alto. As mesmas informações que existem no serviço A devem existir no serviço B.

Eu sei que replicas de informações quando estamos trabalhando com micro-serviços acontece. Mas quando você tem o domínio replicado do outro lado para fazer funcionar, pode acreditar que alguma coisa cheira mal.

Com micro-serviços devemos pensar também nos problemas que antes não existiam. Por exemplo, fazer com que um serviço tenha baixo acoplamento nos força a pelo menos duas coisas: Cada serviço ter a sua própria fonte de dados e utilizar uma ferramenta para troca de mensagem.

Você não cumpre o item “baixo acoplamento” quando seus serviços fazem trocas de mensagens diretas ou fazem leituras em fonte de dados de outros serviços. O seu sistema que deveria ser escalável passa a ser dependente.

Inserir um Kafka ou outra ferramenta similar é algo relativamente fácil, o problema é que eu passo a ter que cuidar de mais um serviço que não seria necessário se o meu sistema fosse um monólito.

Se no momento que você leu a palavra “monólito’ se arrepiou todo é porque possivelmente você já foi afetado pela “onda” e nesse momento deve estar gerando altos custos para a sua empresa sem a necessidade. Claro que tem muita gente que se salva.

Ter um sistema monólito não é um problema. O problema é dividir um sistema no meio por achar que deveria ser em serviços para atender o ego ou pior, querer fazer algo só porque está estudando e achou legal.

Recentemente participei de um projeto em uma outra empresa onde no primeiro dia de desenvolvimento a equipe de “arquitetos” apresentou quais seriam os serviços a serem desenvolvidos. Tudo era da cabeça da equipe de TI e não do negócio. 6 meses depois todos os serviços criados foram unificados para um único sistema e um único banco, mas por quê? Porque dividiram mal os serviços e de tão pequenos ficou inviável manter. Nesse caso especifico eu indico muito a utilização de micro-serviços, o problema foi a divisão que ficou ruim.

Mais uma vez vejam que não estudaram o item mais importante de micro-serviços: “Organizado em torno dos recursos do negócio”.

Mas afinal, quando devo criar um micro-serviço? Uma coisa que aprendi nesses tempos é que os serviços não devem ser a TI a falar e sim o negócio. O seu negócio exige que o sistema seja em serviços?

Um bom exercício para saber dividir seu negócio em serviços é ouvir o negócio. Um exemplo que alguns autores dão é de um e-commerce. Um produto tem vários significados, ou seja, vários negócios. Um produto para o setor de marketing é um nome, sua descrição, imagens, vídeos e principalmente seu preço. Esse “produto do marketing” é o que aparecerá na vitrine do site. Já o produto para o estoque não precisa dos detalhes do marketing e sim da quantidade em estoque. O setor de estoque tem que ter apreço para não deixar esse produto zerar, porque a pior coisa que existe é fazer um brutal marketing e não ter produto para vender. Pessoas do marketing e do estoque são diferentes, falam línguas diferentes e por isso podem ser serviços diferentes. Entendeu a sacada? Agora você tem uma ideia do significado “Organizado em torno dos recursos do negócio”

Nos casos acima note que a divisão dos serviços é que foi errada e não a arquitetura. Isso é igual usar CQRS para um sistema sem complexidade e que tem apenas 4 telas. Em nenhum lugar você vai aprender como pegar o negócio e dividir em serviços. Isso é você que vai ter que fazer com a sua experiência. Se você deseja realmente aprender sobre micro-serviços eu oriento a antes aprender a parte tática do DDD, principalmente sobre oblíquos language, domain experts e também bounded context. Depois você pode naturalmente ir para a parte técnica: Cache, Messaging, API Gateway e por ai vai.

Você não precisa estar preso a um monólito para sempre. Você pode usar a ideia de sistemas distribuídos. Por exemplo, em nossa empresa temos um sistema de gestão de documentos e este usa a extração do texto do documento para uma melhor busca por parte do usuário. O problema é que esta extração do texto era feita no momento do upload do arquivo e isso trazia vários problemas, um deles a demora. Para resolver esse problema criamos um Worker para ser executado no Docker que fica monitorando os arquivos que ainda não foram processados. O usuário com isso não foi mais penalizado e o monólito continua firme e forte.

Para concluir, a dica que deixo é: Antes de já iniciar um projeto pensando em serviços, estude o negócio, ganhe maturidade sobre o assunto e veja se essa arquitetura serve para o seu contexto. Lembre-se, deixe o negócio falar sobre a necessidade e não a sua vontade de implementar. Apenas para deixar claro, de maneira nenhuma sou contra arquitetura A ou B e não existe a errada ou a certa. O que existe é uma arquitetura melhor para o seu contexto.

E a ultima dica, não crie algo custoso para a sua empresa apenas para entrar na onda. Melhor começar no básico ir avançando em serviços aos poucos. Os DEVs, e eu me incluo nessa, temos o prazer de fazer o mais complexo para nos bares com os amigos falarmos que implementamos a arquitetura X ou Y.

Caso você tenha gostado do tema e quer aprender mais sobre DDD, Domain Driven Design, e a um preço super acessível acesse o link para receber a promoção.

Muito obrigado e até a próxima.

Published inDDDMicro-Services

Be First to Comment

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *