Indo Além do Código: A Hora de Entender o "Porquê"
Olá! Chegou um momento importante na jornada de todo desenvolvedor: a hora de evoluir de apenas seguir tutoriais e focar em aulas práticas para realmente começar a entender a engenharia de software em um nível mais profundo. O objetivo é se tornar um(a) programador(a) que sabe não apenas o "como", mas principalmente o "porquê".
É necessário entender quando usar um monolito e quando usar microsserviços.
Muitas vezes nos deparamos com um paradoxo: por que tantas empresas pedem experiência em microsserviços em suas vagas, se a grande maioria das aplicações que conhecemos, incluindo as delas, foram construídas com base em monolitos? Você precisa entender essa dinâmica, porque se você não compreender o motivo por trás de uma decisão de arquitetura, você não vai entender completamente o que está construindo.
O que é um Monólito?
Vamos visualizar um cenário comum. Toda empresa precisa, no mínimo, de um cadastro de usuários. Então, para começar, nosso sistema precisará de:
- Uma aplicação (usando Spring, por exemplo) para cadastrar os usuários.
- Um banco de dados para armazenar as informações desses usuários.
Agora, vamos adicionar uma funcionalidade: esse usuário poderá fazer uma compra. Após a aprovação dessa compra, precisamos pegar os dados desse usuário, como endereço, nome completo e CPF, e enviar para o sistema de entrega.
Se estamos trabalhando com um monólito, todos esses sistemas — o de cadastro de pessoas, o de pagamentos com suas validações, e o de delivery — estarão contidos dentro da mesma aplicação, da mesma base de código.
O monolito é basicamente uma aplicação que faz tudo. É um sistema unificado que possui uma única codebase(o código em si) e, frequentemente, um único banco de dados para todas as suas funções.
Esse código único vai lidar com o
- cadastro de usuários,
- a autenticação,
- o processamento do pagamento,
- a consulta ao banco de dados para obter o endereço e, por fim,
- acionar o serviço de entrega.
Tudo isso está dentro da mesma base de código. É um sistema unificado, um "bloco" único de código, e por isso o chamamos de monolito.
A Grande Vantagem do Monólito: A Comunicação
À primeira vista, parece a abordagem perfeita, certo? Em muitos aspectos, ela oferece grandes vantagens, principalmente na comunicação interna.
Vamos aprofundar nisso. No nosso exemplo, para saber se um usuário pagou, o sistema de entrega precisa dos dados do usuário.
Dentro de um monolito, ele simplesmente acessa a função ou a tabela do banco de dados que está ali, do lado, dentro do mesmo servidor.
Pense no monolito como a sua casa. Se você precisa de uma informação de alguém que mora na mesma casa que você, ela está no mesmo ambiente. É só perguntar, e a resposta vem de forma rápida e direta. Essa é a grande vantagem da comunicação em um monolito: ela é prática e veloz, pois tudo está "em casa".
E os Microsserviços?
Agora, como seria transformar esse mesmo produto em microsserviços? A ideia é que cada funcionalidade principal se torne um serviço independente e focado.
Microsserviços não são serviços pequenos, mas serviços especializados. E há uma diferença muito grande nisso.
Aqui, o cenário vai se complicar um pouco. Teríamos:
- Um microsserviço de Usuários, com seu próprio banco de dados e rodando em seu próprio servidor.
- Um microsserviço de Pagamentos, também com seu banco de dados e servidor independentes.
- Um microsserviço de Delivery, seguindo o mesmo padrão.
Se cada um está em um servidor separado, com seu próprio banco de dados, como eles se comunicam?
Diferente do monolito, onde seu irmão estava na mesma casa, agora é como se ele morasse em outra cidade. Você não pode mais simplesmente "gritar" pela informação. Você precisa fazer uma "ligação", enviar uma mensagem via "whatsapp", ou seja, uma requisição de rede, seja via HTTP ou RPC (Remote Procedure Call).
O fluxo de comunicação se torna mais complexo:
- O microsserviço de Usuário precisa enviar uma requisição para o de Pagamento para validar uma compra.
- O serviço de Pagamento, uma vez que a compra é validada, precisa fazer uma consulta ao serviço de Usuário para obter o endereço de entrega.
- Após receber o endereço, ele precisa enviar todas essas informações para o microsserviço de Delivery.
A Complexidade Adicional
Cada uma dessas comunicações entre serviços precisa ser autenticada. Nenhum serviço pode acessar o outro sem antes se identificar e provar que tem permissão. É como se ninguém pudesse entrar na sua casa sem se autenticar primeiro. Isso adiciona mais uma camada de complexidade ao sistema.
Toda vez que lidamos com microsserviços, estamos aumentando consideravelmente a complexidade do que estamos construindo.
O que antes era uma simples chamada de função dentro da mesma aplicação, agora se transforma em uma série de requisições de rede que precisam de autenticação, tratamento de falhas, latência e muito mais. Esse desafio de gerenciar e monitorar a comunicação e o estado de múltiplos serviços tem um nome: Observabilidade Distribuída (Distributed Observability).
Então, por que as empresas buscam Microsserviços?
Se é uma abordagem tão mais complexa, qual é a vantagem? A resposta, na maioria das vezes, se resume a uma palavra: dinheiro. E, mais especificamente, o estágio de maturidade e os recursos financeiros da empresa.
Mas antes, um fato crucial que responde à nossa pergunta inicial:
Praticamente todas as grandes aplicações que você já usou na vida começaram como monolitos.
É extremamente raro, talvez impossível, ver um novo projeto ou uma nova empresa começando do zero com uma arquitetura de microsserviços. O motivo é simples: monolitos são mais fáceis, rápidos e baratos para começar.
O Desafio do Monólito que Envelhece
Imagine uma codebase que começou lá em 2004. Com o passar dos anos, novas funcionalidades, regras de negócio e equipes foram adicionadas. O que acontece é que o monolito pode se tornar tão grande e complexo que a manutenção se torna um pesadelo.
- Conflitos de Merge: Com uma equipe grande trabalhando na mesma codebase, a chance de um desenvolvedor, sem querer, quebrar a funcionalidade de outro ("skipar") é enorme.
- Código Morto: Funcionalidades antigas e abandonadas se acumulam, e ninguém tem segurança para removê-las, gerando um código "inchado" e difícil de entender.
- Dificuldade de Manutenção: Corrigir um bug ou adicionar uma nova feature pode se tornar uma tarefa lenta e arriscada, pois uma pequena mudança pode ter efeitos inesperados em outra parte do sistema.
Onde os Microsserviços Brilham
É nesse ponto que, quando uma empresa atinge um certo nível de maturidade e, principalmente, tem caixa (dinheiro) para investir, ela pode decidir migrar para uma arquitetura de microsserviços.
O motivo é estratégico e financeiro:
- Times Especializados: Empresas grandes podem se dar ao luxo de ter um time focado apenas no serviço de pagamento, outro no de usuários, e assim por diante. Isso custa mais caro, mas permite que cada equipe desenvolva autonomia e expertise.
- Escalabilidade Independente: Se o serviço de busca recebe 100x mais tráfego que o de faturamento, você pode escalar apenas o serviço de busca, otimizando o uso de recursos.
- Resiliência: Se o serviço de envio de notificações falha, o sistema de pagamento e o de cadastro de produtos continuam funcionando normalmente.
A transição raramente é um "big bang". Geralmente, ela é gradual. A empresa pode, por exemplo, extrair o sistema de pagamentos do monolito e transformá-lo em um microsserviço que se comunica com o restante da aplicação. O Pinterest, por exemplo, possui microsserviços para comentários e notificações que operam junto ao seu sistema principal.
Conclusão: Qual é o melhor? Monólito ou Microsserviço?
Se você chegou até aqui, provavelmente já entendeu que essa é uma pergunta boba.
Não existe uma arquitetura "melhor" ou "pior" em termos absolutos. A escolha da arquitetura depende muito mais da maturidade do negócio, do tamanho da equipe e, claro, do orçamento, do que de uma preferência técnica. Como pessoa desenvolvedora, você não escolhe isso.
- Monolitos: São excelentes para começar. São mais baratos, menos complexos e ideais para times menores e projetos em estágio inicial.
- Microsserviços: São caros e complexos. Exigem times maiores, mais especializados e uma cultura de DevOps madura, mas oferecem escalabilidade, resiliência e autonomia para empresas em crescimento.
A realidade do mercado é esta: quase todas as empresas começam como monolitos e, com o tempo, o crescimento e os recursos, decidem migrar algumas (ou todas) as suas funcionalidades para microsserviços.
E aí, qual é a sua experiência com essas arquiteturas? Deixe um comentário
Top comments (0)