Micro services não são um objetivo, são uma consequência

Em algum momento a palavra aparece numa reunião: o sistema precisa virar micro services.

Micro services é dividir um sistema grande e único em vários sistemas pequenos, cada um responsável por uma parte do negócio e cuidado por um time diferente. O oposto disso, o sistema grande e único, costuma ser chamado de monolito — e o termo é usado como xingamento com mais frequência do que deveria.

O argumento a favor vem pronto: assim cada pedaço evolui no seu ritmo, sem esperar os outros. É verdade. Mas só quando o seu problema é esse. Quando não é, você trocou um sistema difícil por oito sistemas difíceis que agora precisam conversar entre si — e a conversa entre eles vira um problema novo, que antes não existia.

Se você é quem aprova o projeto, não precisa entender de programação para saber se faz sentido. Precisa de três perguntas.

As três perguntas

Existem equipes diferentes que hoje ficam esperando uma pela outra para colocar algo no ar? Esse é o problema que micro services resolve de verdade: times independentes travados na fila um do outro. Se você tem uma equipe só, dividir o sistema não vai acelerar nada. Vai dar a ela oito coisas para cuidar no lugar de uma.

As áreas do negócio têm fronteiras claras? Se ninguém na empresa sabe dizer com precisão onde o cadastro termina e a cobrança começa, essa confusão não desaparece com a divisão. Ela vira uma confusão entre sistemas separados, que é muito mais cara de resolver do que dentro de um só.

Colocar uma correção no ar hoje é rotina ou é evento? Se publicar uma mudança já exige reunião, madrugada e torcida com um sistema, imagine com oito. A divisão multiplica exatamente aquilo que já dói.

Se a resposta for não para as três, dividir só multiplica o problema.

A ordem que costumamos indicar

Quando o caso realmente pede a divisão, ela é o último passo, não o primeiro.

Primeiro, tornar a publicação de mudanças confiável e sem drama — o que no jargão aparece como CI/CD, e na prática significa que subir uma correção deixa de ser um evento arriscado e passa a ser rotina.

Depois, padronizar o ambiente onde o sistema roda, para que ele funcione igual na máquina de quem desenvolve e no servidor de verdade. É o que os containers fazem, e é o que acaba com o "aqui funcionava".

Depois, esclarecer onde uma área do negócio termina e a outra começa. Essa é a parte difícil, e ela é de negócio, não de tecnologia — quem responde é quem conhece a operação, não quem programa.

A separação física em micro services vem por último. E quando chega a vez dela, já quase não custa nada, porque o trabalho pesado foi feito antes. É por isso que ela é consequência, e não objetivo: quando você fez o resto direito, dividir vira uma decisão pequena. Quando não fez, dividir não conserta nada.

Se te apresentaram um projeto de migração, essas três perguntas valem mais que a proposta inteira — e respondê-las é uma conversa que a gente tem de graça.