Monolith or microservices: decide on team size and domain

For most products built by a single development team, a well-structured monolith is the better choice. Microservices mainly solve an organisational problem: several teams that want to build and release on their own. If you do not have that problem, you pay the cost of microservices and get nothing back for it.

Microservices solve a team problem

In 1967 Melvin Conway wrote that an organisation designs systems whose structure copies its own communication structure. The paper was published in 1968 and is now known as Conway's law.

Microservices put that to use. Each team gets one or more services, with its own codebase, its own database and its own release, so teams do not wait for each other.

With one team on the product, that advantage disappears. Everyone already talks to everyone, there is one backlog and one release, and the boundaries between services mostly become places where you do work twice.

What microservices cost

What is a function call inside a monolith becomes a network call that can fail, be slow or expect an old version of a contract. On top of that you get:

• No plain database transactions across services, which means eventual consistency, retries and idempotency.
• Tracing and central logging, or you cannot track down an error.
• A pipeline, monitoring and alerting per service.
• Agreements on versions of APIs and events.
• A local development setup where ten services have to run together.

Martin Fowler called that extra load the "microservice premium" in 2015. In "Monolith First" he wrote that almost all successful microservice stories started with a monolith that grew too big and was broken up. He therefore advises against starting a new project with microservices.

Rules of thumb per situation

There is no hard threshold. These are the rules of thumb I use:

I think teams pick the last option too rarely. Think of image or video processing, a heavy import job or an AI component in Python next to a .NET back end. You pull out that one piece and keep the rest as a monolith.

The domain decides where you cut

A service should fully own a piece of the domain: the logic and the data. If you cannot draw those boundaries clearly yet, you cannot cut well yet either.

Cut in the wrong place and you get a distributed monolith. You recognise it by this:

• Services have to be deployed together.
• Services read from each other's tables.
• A small change touches three or four services at once.

I consider that the most expensive shape there is: you carry the network and pipelines of microservices along with the coupling of a monolith.

The modular monolith as a middle ground

A modular monolith is one application that you deploy as a whole, split internally into modules by domain. Each module has a public interface and its own tables, and tooling in CI guards the boundaries. You get the clear boundaries you were after with microservices, without a network in between.

If you later want to split off a module after all, most of the work is already done. Aleksa describes how to set it up in the modular monolith.

When splitting does pay off

There are good reasons to break up a monolith: teams queue up for the same release, one component needs to scale on its own, part of the system falls under stricter security requirements than the rest, or the old code is so entangled that every change breaks something else.

At ViaLuxury it was that last one. Payments, availability and onboarding were tangled together and no longer maintainable. There we rebuilt the platform around decoupled .NET microservices, with Stripe for payments and Elasticsearch for availability.

If you do go for microservices, look hard at the infrastructure too. A handful of services does not call for Kubernetes yet. Aleksa lays out the options in do you need Kubernetes.

Ownership matters more than architecture

With developers in different locations, clear ownership matters more than the architecture itself. Who owns which module, who reviews changes to it, and where are the agreements written down? You can arrange that in a modular monolith just as well as with microservices.

Microservices do not fix poor communication between locations. If anything they expose it, because every unclear agreement turns into a broken integration. So start with one codebase and clear modules, and split only when there is a concrete reason, such as teams queuing for the same release or a component that has to scale on its own.

Sources

• Martin Fowler: Monolith First (2015)
• Mel Conway: Conway's Law