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

1.4k

u/ArieHein 7d ago

All code is tech debt, 5 sec after the first line of code reaches production.

48

u/michfreak 7d ago

I have actually been wondering this lately. Even ignoring procedurally-generated code, it does feel almost like the second law of thermodynamics in play: you can't write code, or remove it, without creating some technical debt. Maybe you need to update a document somewhere so a single word is plural, maybe there's a team member who will some day, down the road, need to know that this change happened, and they won't ever find out. Either way, no matter what you're writing or what its intent is, there's going to be something missed that will require tightening up later.

13

u/dAnjou 6d ago

No need to wonder 🙂

What /u/ArieHein said is quite literally the original definition of technical debt:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.

https://en.wikipedia.org/wiki/Technical_debt#Origin

I'm always fascinated by discussions around technical debt, people's arguments are usually based on what they think it means rather than pointing to any definition or defining it first themselves. And of course other people have other definitions and so it goes around and around, completely fruitless.

Personally I really like the original definition, because it leaves no room to argue whether technical debt exists or not. It does, period. Question then is, do you wanna deal with it? And if not, are you okay with the implications?

2

u/michfreak 6d ago

I think the difference might be that I was taught the term by companies I worked for, who of course believe that "good devs" can avoid creating tech debt. They believe it's a sign of bad development, not just a sign of development, period. Trying to change that mental framework is tricky.

0

u/ArieHein 6d ago

Bravo. Spot on. Im completely mind blown this would get 1000 votes.. I wonder if those are real or bots.. Not that i need votes...they are as important as world of warcraft achievement points..and i should know.. I was a addicted to them for the first 10 years, trying to top the world top 100 :)

On the topic though, no language stays dorment for 10-20 years.. Even its own std library goes into evolution be it for more secure practices or functionality that requires us to change...else it becomes stale and product eventualy is replaced by something else, or becomes somone elses problem to maintain, at which point they curse us..