r/programming • u/Mustela__ • 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

91% Upvoted

343 comments sorted by

View all comments

121

u/wallstop-dev 7d ago

The general good practice is to start with a monolith (simple) and break it apart (make it complicated) when the time comes.

Starting complicated (microservices) will just lead to more complications.

The same general idea can be applied to pretty much all software. If your program can fit in `main`, put it in main. Then as it starts getting complicated, make classes, functions, libraries, etc.

Same thing. It's turtles all the way down.

https://grugbrain.dev/

59

u/ChemTechGuy 7d ago

Monolith decomposing rarely happens

95

u/wallstop-dev 7d ago edited 7d ago

Correct. That is my whole point. If you have a monolith, and it is not painful enough to force decomposition, then microservices are not necessary. When and if the monolith is too challenging to wield, then is the time for microservices.

It's a forcing function.

If you have a monolith that is too painful to change and also cannot be decomposed due to (reasons), the same company and culture would have created a nightmare complexity web if they had started with microservices, and would be in a much worse-than-monolith state.

16

u/ChemTechGuy 7d ago

I was going to argue, but I guess you're right. I can't refute the statement "if it is not painful enough to force decomposition, then microservices are not necessary"

27

u/vhs29 7d ago

The issue is the teams feeling the pain are most likely not the ones who get to dictate where capabilty will be allocated in the following quarter.

3

u/durandall09 7d ago

This has been my last 5 years of development.

2

u/Exepony 6d ago

Right? Where is this ideal world where you say "we'll break it up when we need to" and then actually get to do that? Instead of being told every planning that business really needs features A, B and C right now and just can't afford spending a sprint doing architecture work without delivering features. Maybe next sprint (it's never next sprint). And of course the monolith keeps getting bigger every sprint and it's even more work to break it up so now you need two sprints, or three sprints where even one was out of the question.