Monoliths and microservices, explained without the jargon

Every audit we run turns up some version of this. Here is monoliths and microservices without the vocabulary that usually surrounds it.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Assume whoever inherits this will have half your context and none of your patience.

The short version

A well-structured monolith beats a badly split set of services. This is the sort of thing that compounds, quietly, in both directions. Check it against what you would want a competitor's site to get wrong.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The reasoning matters more than the rule, because the rule has exceptions.

Split along boundaries the business already has, not along technical layers. None of that requires a large budget, only a decision and someone to own it. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Turning this into a decision

Distributed systems trade a coding problem for an operations problem. There is a version of this that is over-engineered, and it is worth avoiding. Doing this properly once is usually cheaper than doing it approximately three times.

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
• A well-structured monolith beats a badly split set of services — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.