Getting started with monoliths and microservices
This is one of those topics that looks small until it costs you something. A short on-ramp to monoliths and microservices for teams who have not touched it before.
Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
Why this earns attention
A well-structured monolith beats a badly split set of services. It is worth being explicit about, because assumptions differ quietly. Check it against what you would want a competitor's site to get wrong.
Your first week
- Find out what is already in place
- Split along boundaries the business already has, not along technical layers
- Change one thing and measure it
Distributed systems trade a coding problem for an operations problem. Small and consistent beats large and occasional here. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
How to tell if yours is fine
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
Pick the one that would hurt most if it failed, and start there.