The real cost of ignoring monoliths and microservices
Teams tend to reach for this after something has already gone wrong. Nobody bills you for neglecting monoliths and microservices. The cost shows up somewhere else.
Most systems fail at the seams rather than inside any one component. Budget a little time for it every quarter and it never becomes a project of its own.
Where the cost lands
- Time spent on work that should not have been necessary
- Enquiries that quietly never arrive
- A well-structured monolith beats a badly split set of services
- Rework, once the problem is finally visible
Split along boundaries the business already has, not along technical layers. There is a version of this that is over-engineered, and it is worth avoiding. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Making it stick
Distributed systems trade a coding problem for an operations problem. The reasoning matters more than the rule, because the rule has exceptions. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
In practice
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Three things worth confirming about monoliths and microservices before you move on:
- Someone can say what the current setup is without going to look
- Distributed systems trade a coding problem for an operations problem — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.