Mandou bem demais nesse post! Você tocou nuns pontos que doem em muita gente. É que a modinha dos microsserviços pegou forte, né? Muita gente ouviu falar, viu palestra, achou moderno e saiu correndo pra quebrar o sistema antigo em pedacinhos, achando que isso era "evoluir".

O problema é que, como você mostrou, muitas vezes essa pressa pra seguir a tendência, sem parar pra pensar direito, acaba criando os problemas que você listou: serviço que depende do outro pra tudo, todo mundo usando o mesmo banco de dados, uma confusão pra chamar as coisas, ninguém sabendo onde deu erro... Troca-se um problema conhecido por vários novos e escondidos!

Isso mostra que talvez o X da questão nem fosse o sistema antigo (o monólito). Talvez o problema real fosse a falta de organização, a gente não ter parado pra definir direitinho o que cada parte faz e, principalmente, se o time e a empresa estavam prontos pra essa confusão toda que é gerenciar um monte de coisa separada.

Aí fico pensando umas coisas aqui pra gente discutir, especialmente por causa dessa febre dos microsserviços:

Pra quê mesmo? Era necessidade ou só vontade de estar na moda? Antes de sair quebrando tudo, qual era o incômodo real? Precisava mesmo dessa separação toda pra escalar uma parte específica? Ou pra cada time trabalhar de boa no seu canto? Ou foi mais pra seguir a onda, botar no currículo, ou tentar fugir de um código velho sem querer ter o trabalho de arrumar ele de verdade?
Bagunça no time = Bagunça no código? Será que essa dificuldade de fazer os serviços ficarem independentes não é culpa do jeito que a galera se organiza? Se cada time não sabe direito do que é dono, como é que o serviço vai ser independente? A arquitetura do código muitas vezes vira o espelho da organização (ou desorganização) da empresa.
E a dor de cabeça que ninguém conta? A gente fala do custo de servidor, de nuvem... mas e o custo de quebrar a cabeça pra entender como tudo funciona junto? Pra achar um erro que passa por vários serviços? A galera que vende a ideia do microsserviço como solução pra tudo esquece de avisar o tamanho dessa encrenca no dia a dia?
Tentamos arrumar a casa antes de demolir? E os gigantes que ainda usam monólito? Antes de meter a marreta no sistema antigo só porque "monólito é feio" na modinha, a gente tentou dar uma organizada nele? Separar as coisas dentro dele mesmo (o tal do Monólito Modular), melhorar os testes? Às vezes, um sistema antigo bem arrumadinho dá menos trabalho e custa menos. E ó, não é vergonha nenhuma! Pensa em empresas gigantes como o Shopify, que você mencionou. Eles rodam uma plataforma enorme, em grande parte, num monólito Ruby on Rails e dão conta do recado (e como!). Outros exemplos são o GitHub, o Stack Overflow, o Basecamp... todos eles têm arquiteturas com monólitos fortes no centro do negócio e são super bem-sucedidos. Eles provam que um monólito bem feito e bem cuidado pode ir muito longe, talvez até mais do que um monte de microsserviços bagunçados feitos na correria.

No fim das contas, valeu a pena o "hype"? Essa trabalheira toda com serviços separados tá realmente ajudando a empresa (entregando mais rápido, aguentando mais gente usando, etc.) ou só complicou a vida de quem desenvolve e aumentou os custos pra poder dizer que usa "arquitetura moderna", enquanto outros gigantes continuam firmes e fortes com seus monólitos?

Seu post deu um belo sacode na galera! Talvez a pergunta não seja só "você tem microsserviços ou só um monte de pedaços do sistema antigo?", mas também "Por que a gente entrou nessa? Foi por necessidade real ou só pra seguir a modinha? E, sendo honesto, tá melhor agora ou só trocamos um problema conhecido por um monte de problemas novos, mais chiques e bem mais caros, ignorando que monólitos bem feitos funcionam muito bem?"

Valeu por levantar essa bola! Assunto importante pra gente não cair em cilada só porque tá todo mundo falando e esquecer de olhar os exemplos que funcionam.