Desenvolver software nunca esteve tão complexo e ao mesmo tempo tão simples. A complexidade está na quantidade de tecnologias, frameworks, linguagens e padrões que temos disponíveis para desenvolver software. A simplicidade está na facilidade de acesso a essas tecnologias e na facilidade de desenvolver software.
Com a facilidade de desenvolver software, muitas vezes, não nos preocupamos com a qualidade do software que estamos desenvolvendo. A qualidade do software é um fator muito importante para o sucesso de um projeto. É ela que garante que o software seja fácil de manter, fácil de evoluir e fácil de corrigir.
Muitas vezes focamos os nossos estudos e nosso tempo para o aprendizado de novas tecnologias e frameworks, mas esquecemos de estudar e aprender sobre arquitetura de software e isso é um grande erro. A arquitetura de software é o que garante a a manutenibilidade, a evolução e a correção do software.
Decidir qual arquitetura utilizar em um projeto é uma tarefa muito importante e que deve ser feita com muito cuidado. Uma escolha não muito acertada pode trazer muitos problemas para o projeto e para a equipe de desenvolvimento, e grande problema é que esses efeitos colaterais podem não ser percebidos no início do projeto, mas sim ao longo do tempo.
Alguns dos principais problemas que podem ser causados por uma arquitetura de software não muito acertada são grande acoplamento entre os módulos do software, baixa coesão entre os módulos, dificuldade em escalar, problemas de performance, dificuldade em testar entre outros.
Imagine o seguinte cenário: o tempo foi passando, você e sua equipe foram notando que o software está ficando cada vez mais complexo, parece que a cada nova funcionalidade que é implementada, o software fica mais instável, mais difícil de manter, mais difícil de evoluir e mais difícil de corrigir. E agora? O que fazer?
Eis que surge do nada a palavra mágica: Microservices. Microservices é a solução para todos os problemas de arquitetura de software. Microservices é a solução para todos os problemas de acoplamento, coesão, escalabilidade, performance e testes.
Eu concordo que micro-serviços são uma excelente solução para muitos problemas de arquitetura de software, mas não são a solução para todos os problemas.
Você já pensou em refatorar seu código antes de tentar uma solução mais complexa como micro-serviços?
Pensou em estudar e aprender sobre arquitetura de software antes de tentar uma solução baseada puramente em tendências do momento ou em soluções que funcionaram para outras empresas?
A Netflix, Amazon, Google tem soluções ótimas para os problemas de arquitetura de software dela, mas será que essas soluções funcionam para o seu projeto?
Será que está na hora de você e sua equipe pararem de tentar soluções mágicas e começarem a estudar e aprender sobre qualidade e arquitetura de software?
Você não acha que usar micro-serviços para resolver problemas de arquitetura de software é um débito técnico?
Não vou dar resposta para essas perguntas, mas acho que você deveria pensar sobre isso.
Não acho que você nunca deve usar micro-serviços, mas acho que você deve pensar muito antes de usar.
Existem sim casos onde essa arquitetura faz todo sentido, mas existe uma grande quantidade de casos onde essa arquitetura só esta sendo usada para resolver débitos técnicos deixados por uma decisão errada tomada no início do projeto.
Não abomine microservices, mas não os use como solução para todos os problemas.
Estude, aprenda, e tome decisões baseadas em fatos e não em tendências.
Manter um software de qualidade é um trabalho árduo e que exige muito estudo e dedicação, mas é um trabalho que vale a pena.
E você, o que acha? Microservices são débitos técnicos?
