Microservices are Technical Debt
TL;DR:Microservices are technical debt — a conscious trade-off, not shitty code. You gain short-term delivery speed in a narrow area. You pay with increased architectural complexity, fragmented team knowledge, and reduced long-term organizational adaptability. Like all debt, if you never pay it back, the accumulated entropy kills you.
Have you ever wondered that microservices are technical debt?
Just not in the way we're used to using the term: technical debt (TD) doesn't mean shitty code.
Shitty code is shitty code.
TD is when you decide to do something simpler and cut your quality standards to win at something else — getting some expected effect faster.
But since there are no free pies — after getting the temporary expected effect, you have to go back and redo it well — pay the TD. Otherwise the accumulated entropy will slowly kill you.
Notice the difference with shitty code. TD is a conscious decision.
Now back to microservices. They help teams kick out functionality in a narrow area of requirements faster without having to work on the entire product — an approach often justified by the common misinterpretation of Conway's Law. This yields a time gain.
A temporary gain. Just like TD.
But since nothing in this universe is free, the price of such an architecture is:
- making it more complex,
- fragmenting team knowledge and responsibility, and
- reducing your organization's adaptability long-term — the same risk as premature platformization.
Microservices are a technical debt. Something to think about!