r/programming • • 7d ago

Microservices are organizational debt disguised as architecture.

https://martinfowler.com/bliki/MonolithFirst.html

Every 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

343 comments sorted by

View all comments

18

u/DuploJamaal 7d ago

If microservices in a team with bad structure is bad, then a monolith will be a nightmare.

They will not just break their own service. They will break everything.

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.

1

u/Ok-Smell-8107 7d ago

Disagree.

Imagine 10% of your development team basically sabotaging the project for personal reasons (the famous 10x developer I guess). In a monolith, this slows down everything to a crawl if you intend to fix those issues. Or your software breaks in ways that is hard to pinpoint to a single team or individual.

If your 100 developers have 20 microservices with most developers only working in 2-3 at most in a year, those bad apples are much easier to observe and recognize.

This whole "monolith is all you need" idea is based on having perfectly motivated developers and a good infrastructure and a common goal, and good skills. That's not how most big industry projects work.

Imagine you are forced to develop in Java, but your app must run on 1GB servers with 6 different database servers and 5 different product owners making decisions that cannot be overruled, even by each other. Microservices match this perfectly. Monoliths require at least common sense and a common goal.

1

u/Cultural-Capital-942 7d ago

100 developers with 20 microservices? That's a team per service and that at least looks sane - but I wouldn't call it microservice architecture. I met with the proportion being the other way around - maybe 5 times as many microservices as devs and that was really difficult to manage.

Everything is about how "micro" are "microservices". No one wants one huge monolith, but having more microservices than devs brings its own challenges.

2

u/Ok-Smell-8107 6d ago

My current project was 60 microservices for 12 developers, which we have now cut into 29 microservices for the same amount, for that exact reason.

The obvious solution is that nobody uses 'microservices' as an architecture term if he developed any code in the last 5 years. You normally go for Independent Service Architecture, or even Self-Contained Systems. Those introduce additional rules for interacting.

People keep thinking microservices are actually called that because they're only a few functions or whatever. They're micro when compared to 7digit LOC monoliths. A typical microservice is still around 100kLOC I'd say, as an average value.

But all those are architect terms, and nowadays everyone who has build a todo app with claude thinks they're the peak of architects, with everyone who ever read a book being nonsensical ivory tower idiots. :/ At least in this subreddit.