Monoliths and microservices: what to get right first

There is no clever trick in this one, just a handful of decisions worth making deliberately. If you only fix one thing about monoliths and microservices this quarter, make it the first item below.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. If it only works because one person remembers to do something, it does not work yet.

Start here

A well-structured monolith beats a badly split set of services. The cost of getting this wrong is rarely visible on the day it happens. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Then this

Split along boundaries the business already has, not along technical layers. The teams that handle this well are rarely the ones with the biggest budgets. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Eventually

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

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

Pick the one that would hurt most if it failed, and start there.