A teoria é bonita, parece até uma fábula bem contada. Mas a realidade é outra história. No mundo real, essa ideia raramente se encaixa — na prática, em 99% dos casos, as coisas não funcionam desse jeito. É fácil falar quando tudo está no papel, mas quando colocamos a mão na massa, a situação muda completamente.

o que mais vi nessa jornada foram devs seguindo esse caminho, enche o produto que era simples de complexidade e vai embora da empresa. quem fica precisa depois trabalhar em algo complexo em um sistema que algo simples resolveria, e com isso aumenta o custo da empresa, pois para coisas simples precisa de no minimo um pleno por complexidade desnecessaria.

Eu já dei uma consultoria que estavm reclamando da performance do sistema feito em microsserviços. Perguntei porque eles adotaram essa tecnologia e me disseram que era pra performance. Mandei refazer monoliticamente, a performance veio. O nível do deslumbramento é impressionante.

Eu recentemente fui implementar isso em um trabalho, nossa que dor organizar o projeto da forma como se pede nos 12 fatores, muito rigido. Mas é claro que tem contextos que esses 12 fatores são essenciais.
Monoliticamente falando, como que funciona a questão de atualização? Por exemplo, tenho um sistema que partes dele são críticas, necessário executar 24 horas por dia e com um fluxo intenso de informações transacionandos e que conversam com outras API's. E em uma parte do sistema não tão critica precisa subir uma atualização, pois necessitam de realizar um cadastro, por exemplo que esta com bug. Qual um meio de não impactar a parte critica do sistema?
Depende de uma série de coisa, desde a tecnologia usada, a necessidade específica. Pode ser qu tenha executáveis separados ou *scripts* que por definição são separados, pode usar *feature flag*, * blue–green deployment* e várias outras técnicas. Engenheiros acham a solução para tudo, que não é segue modinha.