How to get monoliths and microservices right
The gap between knowing this and actually doing it is where most teams lose ground. The short answer to monoliths and microservices is that it is mostly a sequence of small decisions, not one big one.
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
Why it matters
A well-structured monolith beats a badly split set of services. There is a version of this that is over-engineered, and it is worth avoiding. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
The steps
- Establish what you have today before changing anything
- Split along boundaries the business already has, not along technical layers
- Distributed systems trade a coding problem for an operations problem
- Write down the decision so the next person does not re-litigate it
Distributed systems trade a coding problem for an operations problem. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is the sort of thing that looks like polish right up until it costs you an enquiry.
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
- 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.