Before you invest in monoliths and microservices

The version of this that works is simpler than the version most people imagine. Before you spend anything on monoliths and microservices, it is worth confirming a few things are already true.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Doing this properly once is usually cheaper than doing it approximately three times.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• A well-structured monolith beats a badly split set of services
• You have a way to tell whether it worked

The mistakes we see most

Split along boundaries the business already has, not along technical layers. Getting it slightly wrong is survivable. Ignoring it entirely is not. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Distributed systems trade a coding problem for an operations problem. The cost of getting this wrong is rarely visible on the day it happens. Assume whoever inherits this will have half your context and none of your patience.

The short version

Most systems fail at the seams rather than inside any one component. Three things worth confirming about monoliths and microservices before you move on:

• Someone can say what the current setup is without going to look
• Split along boundaries the business already has, not along technical layers — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.