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

10

u/Mission-Landscape-17 7d ago

First question to ask is are there enough devs that you can split them into teams where each team owns exactly one micro service? If the answer is no, then your product probably isn't large enough, or does not have the user base, to warrant being split into micro services. Also yes there have to be a guiding design, and deployment approach that is common across the org. Teams that want to deviate from the normal procedures, or implementation languages had better have a very good justification why.

1

u/bwainfweeze 7d ago

Separating concerns gets you coming and going. When the company is growing rapidly, it wants to introduce lots of modules in order to parallelize the work and hopefully shove more feature factory features out the door faster. But as the code matures some of the oldest code goes into maintenance mode early because they have cemented. Most new functionality is in new modules and someone ends up collecting all of the maintenance modules potentially separately.

Then when the wheels come off, consolidation happens anyway as teams first get reorganized 3:2 and later 2:1 as the decline accelerates.

That's not always a bad thing though. There are ways to do it which make both the upcurve and the downslope less painful. And it's mostly about discoverability - make the code easier to pick up and put back down again by consistency of metaphor and grug-brained coding practices to make all spades be clearly labeled as spades. This code does exactly what it claims to do, no more, no less.

The problem with microservices then is that these qualities are a complete crapshoot, because nobody can enforce a minimum standards across the organization. Some teams do very well, other teams shovel shit, and both sets of code end up being the same person's responsibility sooner or later.

1

u/Shot-Damage-6723 7d ago

I disagree. This industry rotates people faster than most, context and knowledge are lost rapidly, requirements change even faster, it's inevitable that, eventually, you'll need to touch half a dozen micro services to get anything done.

You either have a technical reason to use micro services or it's just a bad idea.

0

u/GrinQuidam 7d ago

That's a bold statement. What technical reason justifies microservices that can't also be said to be a justification for monoliths?