Arrumar a casa antes de demolir: Pulamos essa etapa na ânsia pelos microsserviços?
E aí, pessoal!
Tenho pensado muito numa coisa que surgiu em outras discussões: aquela hora que o sistema legado, o nosso bom e velho monólito, começa a pesar. Deploy fica lento, mexer numa coisinha quebra outra lá longe, a complexidade parece um monstro crescendo no armário...
Nessa hora, com toda a modinha e o hype em cima dos microsserviços, a reação quase automática de muitos times (e gerentes, e arquitetos...) é sacar o martelo da demolição e gritar: "Vamos quebrar tudo em microsserviços! É o futuro!". Soa moderno, escalável, currículo agradece, né?
Mas aí me bateu a reflexão em cima de uma frase: a gente realmente tentou arrumar a casa antes de decidir que precisava demolir tudo?
O que seria "arrumar a casa" no nosso mundo de código?
- Dar um trato sério no código: Refatorar aquelas partes mais críticas, simplificar o que tá complicado demais.
- Blindar com testes: Criar testes automatizados (unitários, integração) pra gente poder mexer com mais confiança, sem medo de quebrar tudo escondido.
- Organizar as gavetas: Separar melhor as responsabilidades dentro do próprio monólito. Criar módulos mais claros, com limites bem definidos (o famoso "Monólito Modular"). Muitas vezes, só isso já melhora MUITO a organização.
- Agilizar a "entrega": Melhorar o processo de CI/CD do próprio monólito. Builds mais rápidos, deploys mais seguros e frequentes. Às vezes a dor não é o código em si, mas a dificuldade de colocar ele em produção.
- Pagar as contas atrasadas: Atacar aquelas dívidas técnicas que mais atrapalham o dia a dia.
Por que se dar ao trabalho de "arrumar a casa"?
- Menos risco e custo inicial: Uma reforma bem planejada geralmente é menos traumática e mais barata do que uma demolição e reconstrução completa (migração pra microsserviços).
- Entendimento profundo: Ao reformar, você é forçado a entender muito melhor a estrutura atual, os problemas reais e o domínio do negócio. Esse conhecimento é ouro, mesmo que você decida migrar depois.
- Pode ser o suficiente: Muitas vezes, os problemas que levaram à ideia de "demolir" (lentidão no desenvolvimento, dificuldade de deploy) podem ser resolvidos ou muito aliviados com essa "reforma". Talvez a complexidade distribuída nem seja necessária!
- Prepara o terreno: Se, mesmo depois da reforma, a demolição (extrair serviços) ainda for necessária, você vai fazer isso a partir de uma base muito mais sólida e organizada. É como começar a fazer os "puxadinhos" (extrair serviços aos poucos, Strangler Fig) depois que a estrutura principal da casa está firme.
- Prova Real que Funciona: E não pensem que isso é só pra sistema pequeno! A prova de que "arrumar a casa" funciona mesmo em larga escala são exemplos de gigantes como Shopify, GitHub, Stack Overflow e Basecamp/Hey. Muitos deles mantêm um "casarão" monolítico (ou boa parte dele) bem cuidado no centro do negócio, mostrando que essa abordagem pode ser extremamente bem-sucedida e escalável, sem precisar cair na complexidade total dos microsserviços só por seguir a moda.
A questão que fica é: será que muitas vezes culpamos o "prédio" (a arquitetura monolítica) quando o problema real era a "falta de manutenção", a "bagunça interna" e as "gambiarras" acumuladas (más práticas, falta de testes, acoplamento desnecessário)? Jogar a culpa só na arquitetura é fácil, mas nem sempre é justo.
Queria lançar a reflexão pra comunidade:
- Vocês já viveram essa situação? Optaram por "reformar" ou foram direto pra "demolição"? Como foi a experiência?
- Conseguiram resultados bons "arrumando a casa" de um monólito, fazendo ele viver mais e melhor? Quais estratégias usaram?
- Em que cenários vocês acham que não tem jeito, a "demolição" (ir pra microsserviços) é realmente o único caminho, mesmo após tentar a reforma?
- Será que a gente, como indústria, pula muito a etapa da "reforma" por causa do brilho da novidade e da pressão por "modernizar"?
Bora trocar uma ideia sobre isso? Acho que tem muito aprendizado aí!
Abraços!
Em microserviços meu time e eu sempre partimos do monolitico pro microserviços, o grande problema ao meu ver quando entra nessa abordagem com um time pequeno começa a complicar muito a manutenção, principalmente se não tem bem fixado uma cultura de monitoramento. Nas minha carreira, normalmente quebrar pra uma arquitetura de microserviços faz sentido quando tem muita gente mexendo na mesma base de código, mas muitas vezes o que acontece é criar grandes serviços o que não é microserviços, exemplifico: meu trabalho anterior tinha uma API de logistica, financeiro, carrinho e etc. A equipe era de uns 30 devs e cada time tinha de 4 a 5 pessoas cuidando de 2 a 3 serviços em média, não era serviços pequenos por exemplo o financeiro era bem grande, mas funcionava esse esquema. Acho que foi o mais perto que cheguei num sistema de microserviços e funcionava bem. Por outro lado já trabalhei numa startup com 5 dev e começamos a quebrar um monolito em microserviços e isso meio que não funcionou aumentava muito a dificuldade de manter e o time não tinha uma cultura de monitoramento muito sólida. Outra situação que quebrar um monolito funciona é migrar pra outra linguagem/framework por exemplo trabalhei num sistema java que era um monolito e foi quebrado em microserviços em rails era um time de uns 15 devs e foi um desafio, mas fazia até sentido por que era uma forma de mudar a stack de forma gradual, mas sei que depois que sai houve desafios de manutenção por ter vários serviços e poucos devs, além do problema também de monitoramento dos serviços.
No meu caso eu diria que só se deve quebrar um monolito em serviços menores se for necessário pois trás outros desafios, mas, como disse ali não trabalhei num lugar com microserviços "by the book" então possivelmente minha opinião tem um viés.
A ultima questão acho que é mais importante, muitas mudanças vem do desejo do time de seguir as têndencias, enquanto tem gente que trabalha a 30 anos com Progress e 4GL. Os dois acho que são problemáticos, mas, o importante é ter um equilibrio, evoluir sim a plataforma, mas quebrar seja em grandes serviços ou microserviços é necessário o time sentir uma necessidade, seja trabalhar com mais stacks, ter um time grande mexendo na mesma base ou ainda ter partes do código que precisam ser separados para algum tratamento especial.
Além disso foi o que você disse, não adianta separar em serviços menores, se não tem uma boa cobertura de testes, um pipelile de CI/CD e colocar monitoramento.
Achei que eu tinha postado isso :D Porque eu falo sempre disso e muitas vezes do mesmo jeito, citos esses exemplos.
Sobre a questão do site/app pequeno (é engraçado que as pessoas perderam tanto a noção das coisas que acham que monótito ou microsserviços é algo só para web, e não é, mas provavelmente se não for para web é provável que o time já tenha mais competência e dificilmente vai adortar microsserviços nisso).
Aliás, em time pequeno nem deve passar pela cabeça a palavra microsserviços.
Eu já passei pela experiência de reformar e de demolir, mas nunca para microsserviços, foi mudanaça de tecnologia ou mudar tudo porque o legado era impraticável. Os resultados sempre foram bons.
O caminho dos microsserviços só pode se dar em equipes enormes, mas enormes mesmo, que não estejam conseguindo gerenciar isso, e a equipe esteja preparada para desenvolver algo mais complexo, porque ms são mais complexos. Além disso precisa fazer um experimento (curiosamente ninguém fala em MVP nisso, né? Porque adotam MVP com receita de bolo, modinha, não porque sabem o que está fazendo) e precisa provar que será melhor, sem entrar com um viés. Na verdade pode ter um viés, de não querer microsserviços, assim fica mais garantido.
Sua última pergunta é um enorme "sim". Mas nem todo mundo é assim, existem pessoas competentes de verdade, e as outras são só pessoas comunicativas, que são convencer, que são políticos.
Eu sou engenheiro, não sou político. Eu não faço nada para agradar, eu faço para funcionar. Se você ver alguém querendo agradar muito, desconfie, político que tem cargos de governo e políticos na iniciativa priva ou até na vida particular só tem um interesse, e você não vai se beneficiar disso a não ser que ele precise de você para alcançar seu objetivo.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).