Jean Pierre Lessa e Santos Ferreira, especialista em tecnologia, software e inteligência artificial, nota um padrão recorrente em times de tecnologia que adotam microsserviços: a decisão costuma ser tomada com base no que as empresas mais admiradas do setor fazem, não com base no que o contexto atual do projeto realmente exige. Com isso, o resultado é uma arquitetura projetada para escala que o produto ainda não tem, com complexidade operacional que a equipe ainda não está preparada para absorver.
Microsserviços resolvem problemas reais, mas resolvem problemas específicos, de times específicos, em estágios específicos de crescimento. Por isso, antes de qualquer decisão arquitetural, vale entender exatamente quais problemas essa abordagem foi criada para resolver.
O que os microsserviços realmente oferecem?
A proposta central é dividir uma aplicação em serviços menores, independentes, que se comunicam por interfaces bem definidas. Cada serviço pode ser desenvolvido, testado e escalado de forma autônoma. Para organizações com times grandes e domínios de negócio bem delimitados, esse modelo traz ganhos concretos de velocidade de entrega. A infraestrutura de cloud computing moderna foi projetada para esse tipo de arquitetura, com contêineres e orquestração que reduzem o custo operacional.
Quando a complexidade supera o benefício?
Jean Pierre Lessa e Santos Ferreira é direto sobre o cenário oposto: times pequenos trabalhando em produtos novos, com domínios de negócio ainda sendo descobertos, pagam um custo alto para operar uma arquitetura distribuída sem colher os benefícios que ela foi projetada para entregar.
Além disso, a comunicação entre serviços introduz latência e pontos de falha que um monolito bem estruturado não tem, uma vez que a rastreabilidade de erros em sistemas distribuídos exige ferramental de observabilidade que precisa ser configurado e mantido. O problema não são os microsserviços em si, mas a adoção de uma solução para problemas que o projeto ainda não tem.
Monolito modular: a alternativa que poucos consideram
Existe um caminho intermediário que times de engenharia de software experientes adotam com frequência crescente: o monolito modular. A aplicação é construída como um único processo implantável, mas organizada internamente em módulos com fronteiras bem definidas e baixo acoplamento entre domínios.
Conforme aponta o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, essa abordagem entrega boa parte dos benefícios organizacionais dos microsserviços sem a complexidade operacional de um sistema distribuído. Dessa forma, quando o produto crescer ao ponto em que a separação fizer sentido, os módulos já terão as fronteiras necessárias para a migração fluida.
A decisão arquitetural que determina anos de trabalho
Jean Pierre Lessa e Santos Ferreira reforça que arquitetura de sistemas é uma das decisões com maior custo de reversão em um projeto de tecnologia. Por isso, mudar a estrutura fundamental de uma aplicação em produção, com times trabalhando e usuários ativos, é caro, lento e arriscado.
Isso não significa que a decisão precisa ser perfeita desde o início. Significa que precisa ser consciente, baseada no contexto real do projeto, com clareza sobre quais problemas está resolvendo hoje e quais está criando para amanhã. Jean Pierre Lessa e Santos Ferreira representa o perfil de CTO (Chief Technology Officer, Diretor de Tecnologia) que trata essas decisões com o rigor que elas exigem, sem seguir tendências de mercado por inércia.
Autor: Diego Rodríguez Velázquez
