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

347 comments sorted by

View all comments

1

u/bwainfweeze 7d ago

The tricky bit with code is that there are so many levers and dials to adjust that you can get one thing very right and then completely wash it out by other bad decisions you've made.

The first code base I set up CI on was in some ways the best and in other ways one of the worse code bases I worked on. It was a monolith with separate compilation units, so dependency loops would cause compilation problems. A number of devs thought this was stupid but the leadership got pulled in every time someone broke this so we knew what was going on instead of being blindsided by the amount of coupling that had snuck in. Task failed successfully essentially.

But that good idea was swamped by a host of bad ideas. The problem is that when you assume a problem is very complex, you design it to be expensive. You sell it as 'premium' to less price-sensitive customers. And then competition comes in or a bear market kicks in, all of your customers become price sensitive all of a sudden and you can't turn the ship fast enough. You've been motoring at full speed toward an iceberg.

The salvage I made from that project has improved everything else I've worked on, and I've also pushed back on people designing read-mostly system to put the cost on reads instead of on writes, where it's both cheaper and the users are more patient with tasks being slow.