The argument here, as far as I care to understand it rn, seems to be that micro services could actually live up to the promises if you follow ALL the rules religiously.

From personal experience, the problem is complexity. Which ends up costing money. At a certain scale, splitting off separate services may or may not make sense. But always building anything and everything as a set of black boxes that only communicate over network APIs, each potentially with their own database; is one of those ideas that sounds like fun until you've had a taste of the problems involved; especially if you have strong ACID requirements, or want to debug pieces in isolation.

> micro services could actually live up to the promises if you follow ALL the rules religiously.

To be fair, I think this is true of nearly everything (well, except maybe Agile). Like, yeah, a monoliths work great IF you rigorously follow software engineering best practices about isolation, coupling, concurrency, and overall project organization ... but in real life they usually turn into a tangled mess of broken abstraction boundaries and encapsulation-breaking hacks.

(that said I'd still much rather untangle and refactor a poorly organized monolith than a mush of poorly factored microservices )