Five mistakes teams make with monoliths and microservices

The gap between knowing this and actually doing it is where most teams lose ground. These are the ones we run into repeatedly when we audit monoliths and microservices.

Most systems fail at the seams rather than inside any one component. If two people in the business would answer this differently, that gap is the actual problem.

The mistakes we see most

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• A well-structured monolith beats a badly split set of services
• Split along boundaries the business already has, not along technical layers
• Never checking whether the fix actually worked

Distributed systems trade a coding problem for an operations problem. None of that requires a large budget, only a decision and someone to own it. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Turning this into a decision

How to tell if yours is fine

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.