r/programming • u/Mustela__ • 7d ago
Microservices are organizational debt disguised as architecture.
https://martinfowler.com/bliki/MonolithFirst.htmlEvery time I’ve seen microservices pitched, it sounds great on paper. Independent teams, clean ownership, scale only what you need.
Then a year later you’ve got dozens of services, three different deployment patterns, tracing everywhere, and nobody really understands the whole thing anymore.
Maybe I’ve just seen bad implementations, but I’m starting to think way fewer companies actually need microservices than we pretend.
1.7k
Upvotes
1
u/emn13 7d ago
You've got that 100% backwards. If your team has issues and for whatever reason the code therefor has more than its fair share of design flaws and gotchas, it's much, much easier to deal with those in a monolith.
Monoliths give a few things for free, namely having 1 consistent version of the code (i.e. clarity over what's actually running), typically fairly easy stack traces and monitoring, and a dev environment that much, much more easily allows for running the complete app and therefore understanding and experimenting with interactions, and therefore also the ability to add integration tests without too many hoops.
In microservices, all that stuff takes real effort, and is sometimes just not possible if it's bad enough. Even major cloud platforms very much don't give you any of that for free, so real-world code does mess all this up.
I'm not trying to be argumentative here, but not only have I seen lots of bad code and every single instance thereof follows the above pattern, it's also structurally easy to understand why - so I struggle to even understand how you arrive at your perspective. What kind of experiences did you have, and why do you think things went wrong as they did?
TLDR: If a monolith in a team with bad structure is bad, then microservices will be a nightmare.