DEV Community: Amando dos Santos Neto

Monólito ou Microsserviços? Lições de Entrevista, o Dilema Fowler-Tilkov e Guias Práticos

Amando dos Santos Neto — Mon, 19 Oct 2026 20:42:09 +0000

Em uma entrevista para uma vaga de Engenheiro de Software, fui questionado sobre quando usar microsserviços e quando não usar. Minha resposta foi muito vaga e percebi que não convenci o entrevistador. Por isso, resolvi pesquisar mais a fundo sobre essa questão. Li sobre os dilemas de Martin Fowler e Stefan Tilkov, além de outras referências, e percebi que a resposta nem sempre é simples. Já participei de dois projetos que usavam microsserviços e, em ambos, a decisão já havia sido tomada antes da minha chegada.

Ainda não vivi a experiência de tomar a decisão de qual arquitetura é mais apropriada para um projeto do zero, mas espero estar preparado quando a oportunidade surgir.

Recentemente, li dois textos que discutem o dilema arquitetural entre iniciar o desenvolvimento de um novo sistema de software como um monólito ou adotar diretamente uma arquitetura de microsserviços. Martin Fowler defende a estratégia de começar com um monólito, argumentando que isso evita complexidade inicial desnecessária e permite compreender melhor os limites dos domínios antes de fragmentar o código. Em contrapartida, Stefan Tilkov contesta essa visão, afirmando que iniciar com componentes separados é mais eficaz, pois os monólitos tendem a gerar um acoplamento excessivo que dificulta futuras divisões. Enquanto Fowler enfatiza que a maioria dos casos de sucesso com microsserviços surgiu de monólitos que cresceram organicamente, Tilkov acredita que planejar subsistemas independentes desde o início previne conexões problemáticas que são difíceis de desfazer depois. Ambas as fontes reconhecem que a experiência da equipe, a complexidade do sistema e o conhecimento do domínio são fatores cruciais para definir qual abordagem adotar em cada projeto específico.

Na minha primeira experiência com microsserviços, os serviços eram isolados e não havia comunicação direta entre eles. Já na segunda, essa comunicação era fundamental para o funcionamento da arquitetura. Nesse período, pude vivenciar na prática as preocupações documentadas na literatura sobre microsserviços, especialmente a importância do uso rigoroso de padrões e boas práticas.

Quando usar a Arquitetura Monolítica (e a estratégia Monolith First)
O monólito é a opção mais oportuna quando a prioridade inicial é a velocidade de desenvolvimento, a simplicidade operacional e a rápida validação do produto.

Startups e Validação de Novos Produtos (Greenfield): Quando um produto está no início, a prioridade máxima é testar hipóteses com os usuários e acelerar o ciclo de feedback (aplicando o princípio YAGNI). Optar por microsserviços logo no início adiciona o atraso do chamado Microservice Premium (o custo operacional de gerenciar múltiplos serviços) antes mesmo de saber se o produto é viável no mercado.
Fronteiras de Domínio (Bounded Contexts) Incertas: Martin Fowler aponta que identificar os limites exatos entre os serviços é um grande desafio até para arquitetos experientes. Refatorar módulos dentro de um monólito é simples; mover funcionalidades entre microsserviços distribuídos exige um esforço imenso.
Equipes Enxutas ou sem Maturidade DevOps: Monólitos possuem um ciclo de desenvolvimento, teste, depuração e implantação muito mais simples e integrado. Operar microsserviços exige conhecimentos consolidados em infraestrutura de nuvem, conteinerização, automação de CI/CD e monitoramento de sistemas distribuídos.
Estratégia Monolith First (Martin Fowler): Consiste em iniciar com um monólito bem estruturado em módulos internos para compreender a complexidade do sistema e descobrir suas fronteiras reais. Conforme a aplicação cresce, extraem-se microsserviços gradualmente nas bordas ou reescreve-se o sistema aproveitando o aprendizado acumulado (Sacrificial Architecture).

Quando usar a Arquitetura de Microsserviços (e a visão Don't Start with a Monolith)
A arquitetura de microsserviços torna-se oportuna quando a aplicação atinge alta escala, grande complexidade de domínio e necessita de autonomia para múltiplos times.

Domínio Maduro e Bem Compreendido: Stefan Tilkov argumenta que, se a meta final do projeto é ter microsserviços e o domínio já é profundamente conhecido (como na reescrita ou segunda versão de um sistema), começar com um monólito pode ser um erro. No monólito, os componentes tendem a criar acoplamentos fortes no banco de dados, em bibliotecas compartilhadas e em chamadas de memória, tornando a separação posterior extremamente difícil ou quase impossível.
Paralelismo entre Múltiplas Equipes: O benefício fundamental dos microsserviços é criar limites rígidos que permitem que equipes separadas desenvolvam, testem e façam deploys de forma autônoma, sem interferir nos fluxos das demais.
Escalabilidade Granular e Resiliência: Quando serviços específicos sofrem altas variações de carga (como módulos de busca, recomendações ou pagamentos em plataformas como Netflix e Mercado Livre), é possível alocar recursos apenas para o serviço demandado, em vez de escalar todo o sistema. Além disso, se um microsserviço falhar, os demais continuam operando, evitando um ponto único de falha (Single Point of Failure).
Flexibilidade Tecnológica e Ciclos de Deploy Rápidos: Cada serviço pode adotar linguagens, frameworks e bancos de dados mais adequados para a sua tarefa específica, além de permitir atualizações frequentes sem a necessidade de retestar a aplicação inteira.

E você, já precisou tomar essa decisão? Poderia compartilhar os detalhes?

Fontes:

https://martinfowler.com/articles/dont-start-monolith.html

https://martinfowler.com/bliki/MonolithFirst.html

https://aws.amazon.com/pt/compare/the-difference-between-monolithic-and-microservices-architecture/

https://www.ibm.com/br-pt/think/topics/monolithic-vs-microservices

https://dev.to/alexnicolascode/monolito-vs-microsservicos-quando-usar-cada-arquitetura-o0n

https://www.rocketseat.com.br/blog/artigos/post/monolito-vs-microservices-como-escolher-arquitetura

Imagem criada com auxílio de Inteligência Artificial (Gemini / Imagen 3)

Da Insegurança à Produtividade: Minha Primeira Experiência Real com IA no Desenvolvimento de Software

Amando dos Santos Neto — Thu, 08 Oct 2026 18:14:13 +0000

No início deste ano, tive minha primeira experiência prática com Inteligência Artificial no ambiente de trabalho. O desafio inicial foi usar a IA para extrair regras de negócio a partir de um sistema legado no AS/400. Esse trabalho foi realizado diretamente na base de código COBOL, sem qualquer alteração no sistema. Uma vez extraídas as informações, o resultado era revisado em conjunto com um especialista na linguagem.

Em seguida, dei o próximo passo: utilizar a IA para desenvolver novas soluções em Java, Spring Boot e Google Cloud Platform (GCP). Confesso que, no começo, é um tanto assustador ver a IA gerando códigos e criando testes de forma tão rápida. Nessa primeira fase, eu dependia muito da criação manual de prompts. Com o tempo, evoluí para o uso de SDD (Spec Driven Development ou Desenvolvimento Orientado a Especificações), o que otimizou drasticamente a qualidade e a precisão do código gerado.

Como eu já acompanhava alguns artigos sobre o impacto da IA no desenvolvimento, minha grande preocupação sempre foi a revisão de código (code review). É fácil revisar poucas linhas, mas fazer isso quando a IA produz centenas ou milhares de linhas é outra história. Tornar essa revisão totalmente manual seria inviável, indo contra a proposta de trazer mais produtividade ao time. Essa etapa me trouxe bastante insegurança no início; afinal, como você não escreveu aquele código do zero, sente que, a priori, não tem o controle total da situação.

Para mitigar esse risco, adotei uma estratégia clara: antes de subir a aplicação, a regra de ouro é garantir que todos os testes unitários rodem com sucesso. Essa se tornou a principal barreira para verificar se a IA quebrou alguma funcionalidade existente. Em seguida, a aplicação é implantada para testes funcionais. Nas implementações em que utilizei IA, os testes passaram em 95% das vezes.

Alguns pequenos bugs foram encontrados apenas na fase de QA (Quality Assurance), mas a maioria estava relacionada à especificação e não ao código em si. Por exemplo, houve um cenário em que uma determinada query deveria usar a cláusula LIKE, mas a IA não a incluiu simplesmente porque o detalhe não constava na especificação. Outro problema identificado no QA foi uma requisição que retornava o status 200 OK, mas uma das tabelas envolvidas não era atualizada porque uma exceção interna não havia sido tratada.

Passada essa fase inicial de adaptação, o processo se torna menos tenso. O código gerado fica cada vez melhor e a própria revisão de código passa a contar com a análise da IA. Obviamente, o processo exige um refinamento constante das instruções, pois sem melhorias na especificação, a geração do código fica comprometida. Hoje, vejo a IA como meu pair programmer, uma parceira que ajuda em todo o ciclo de vida do software — desde o refinamento técnico até a implementação final.

Sou muito grato à empresa que me deu a oportunidade de sair da teoria e começar a utilizar a IA de forma responsável e profissional. A Inteligência Artificial veio para transformar o mercado e veio para ficar. Se ela vai acabar com o papel do programador tradicional? Não tenho essa resposta. Mas sei que a mudança já começou, e eu escolhi não ficar para trás.

Versão em inglês.

From Uncertainty to Productivity: My First Real-World Experience with AI in Software Development

Amando dos Santos Neto — Thu, 08 Oct 2026 18:09:10 +0000

Earlier this year, I had my first practical experience integrating Artificial Intelligence into my daily workflow. The initial challenge was using AI to extract business rules from a legacy AS/400 system. This work was done directly on the COBOL codebase without making any changes to the code itself. Once the rules were extracted, the output was reviewed alongside a COBOL specialist.

Shortly after, I took the next step: using AI to develop new solutions in Java, Spring Boot, and Google Cloud Platform (GCP). I must admit, it is quite intimidating at first to watch an AI generate code and run tests so rapidly. During this initial phase, I relied heavily on manual prompting. Over time, I transitioned to SDD (Spec Driven Development), which drastically optimized the quality and precision of the generated code.

Since I had already been reading articles about AI in development, my biggest concern was always code review. Reviewing a few lines is easy, but doing so when the AI produces hundreds or thousands of lines of code is a completely different story. Relying solely on manual reviews would be unfeasible and would defeat the purpose of using AI to boost team productivity. This stage made me feel quite insecure at first; after all, since you didn't write that code from scratch, you feel a lack of control over the situation.

To mitigate this risk, I adopted a clear strategy: before deploying the application, the golden rule is to ensure that all unit tests run successfully across the entire application. This became the main safety net to verify that the AI hadn't broken existing functionalities. Next, the application is deployed for functional testing. In the implementations where I used AI, the tests passed 95% of the time.

A few minor bugs were caught during the QA (Quality Assurance) phase, but most of them were related to the specification rather than the code itself. For instance, there was a scenario where a specific query was supposed to use a LIKE clause, but the AI didn't include it simply because it wasn't specified. Another bug found in QA involved a request that returned a 200 OK status, but one of the underlying tables failed to update under certain conditions due to an unhandled exception.

Once you get past that initial adaptation phase, the process becomes much less stressful. The generated code keeps getting better, and the code review process itself now includes AI analysis. Of course, this requires a continuous refinement of instructions—without improving the specifications, the quality of the generated code suffers. Today, I view AI as my pair programmer, a partner that assists throughout the entire software development lifecycle, from technical refinement to final implementation.

I am deeply grateful to the company for giving me the opportunity to move past theory and start using AI in a responsible and professional manner. Artificial Intelligence is here to stay and change the game. Will it replace programmers? I don't have the answer to that. But I do know that change is happening right now, and I choose not to be left behind.

Portugues version