A decision table for product and engineering leads, with the costs that rarely make it into the architecture slide.
In short
Choose a monolith, ideally a well-structured modular one, when one or a few teams build a product whose domain is still changing. Choose microservices when several teams need to deploy independently, parts of the system have very different scaling needs, and you can afford the platform, monitoring and on-call work that distributed systems demand.
Microservices are the default answer in many architecture discussions, but they are a trade-off, not an upgrade. This comparison is written by Devies, a Gothenburg-based product and engineering consultancy, for CTOs, product leads and senior developers who need to decide how to structure a new product or a growing codebase. It sets out what each option is, what it really costs, and the signals that should tip the decision.
What is the difference between a monolith and microservices?
A monolith is an application that is built, tested and deployed as one unit, while microservices split the application into small services that are deployed independently and talk over the network. Both can be well or badly designed; the difference is where the boundaries sit and what crossing them costs.
James Lewis and Martin Fowler described the microservice architectural style in 2014 as building a single application as a suite of small services, each running in its own process, organised around business capabilities and deployable through automated tooling. Three definitions keep the discussion precise:
- A monolith is one deployable unit with one codebase and usually one database. A change anywhere means redeploying the whole application.
- A modular monolith is still one deployable unit, but its code is divided into modules with clear interfaces and owned data, so that teams can work in parallel without stepping on each other.
- A microservice is a small, separately deployed service that owns its data and exposes it only through an API or events.
The modular monolith is the option most often missing from the debate. It gives you most of the structural benefits of service boundaries, such as clear ownership and contained changes, without paying for network calls, distributed transactions and many deployment pipelines.
What does a distributed architecture really cost?
A distributed architecture costs more to build, run and debug than a monolith, and that premium only pays off when it removes a bottleneck you actually have. Fowler calls this the microservice premium: the extra work of automated deployment, monitoring, failure handling and eventual consistency that slows a team down until the system is complex enough to justify it.
In practice the premium shows up in five places:
- Platform. Each service needs a build pipeline, a deployment target, configuration and secrets. Many teams run services on Kubernetes, which the Kubernetes documentation describes as a platform for managing containerised workloads and services. It is not a complete platform: logging, monitoring, middleware and databases are left for you to choose and operate.
- Observability. A single user request may cross five services. Without distributed tracing, correlated logs and service-level metrics, finding the cause of a slow page becomes guesswork.
- Data consistency. Each service owns its data, so a business transaction that spans services needs events, retries and compensating actions instead of one database transaction.
- Testing. Contract tests and test environments with several services running replace a large part of what one integration test suite did before.
- People. Someone has to be on call for each service, upgrade its dependencies and keep its API stable. Small teams feel this most.
None of this is a reason to avoid services. It is a reason to know what you are buying. If your main problem is slow releases caused by an unclear codebase, splitting it into services often moves the mess onto the network.
Monolith or microservices: a decision table
The right choice depends on team structure, domain stability, scaling profile and operational maturity far more than on technology preference. Use the table to score your situation honestly.
Criterion
Monolith
Modular monolith
Microservices
Number of teams
Monolith
One team
Modular monolith
One to a few teams
Microservices
Several teams that need to release independently
Domain understanding
Monolith
Early, changing fast
Modular monolith
Fairly clear, boundaries emerging
Microservices
Stable, well understood boundaries
Deployment
Monolith
One pipeline, one release
Modular monolith
One pipeline, module ownership
Microservices
Many pipelines, independent releases
Scaling
Monolith
Scale the whole application
Modular monolith
Scale the whole application
Microservices
Scale each service separately
Operational load
Monolith
Low
Modular monolith
Low to medium
Microservices
High: platform, tracing, on-call per service
Typical hosting
Monolith
App service or a few containers
Modular monolith
App service or a few containers
Microservices
Container platform such as Kubernetes
Cost of a wrong boundary
Monolith
Low, refactor in code
Modular monolith
Low to medium
Microservices
High, change APIs and move data
Main risk
Monolith
Tangled code as the product grows
Modular monolith
Module rules erode without discipline
Microservices
Distributed complexity without the benefits
Choose a monolith or modular monolith when
- one or a few teams build the product, and they can coordinate releases;
- the domain is still being discovered, so boundaries will move;
- you do not yet have automated deployment, tracing and on-call routines in place;
- load is predictable and the whole application can scale together at acceptable cost.
Choose microservices when
- several teams are blocked by each other's release schedules and need to deploy on their own;
- one part of the system has a very different load, availability or security profile from the rest;
- the business capabilities are stable enough that you can draw boundaries you will not redraw next quarter;
- you have, or will fund, the platform team or engineering practices to run distributed systems well.
Fowler's Monolith First argument is useful here: almost all successful service architectures he had seen started as a monolith that was split once the boundaries were understood. Starting with services means guessing those boundaries before you have the knowledge to draw them.
How do you move from a monolith to services without a rewrite?
You move gradually: extract one well-understood capability at a time, behind a stable interface, while the rest of the monolith keeps running. A big-bang rewrite stops feature work for months and usually reproduces the old problems in a new shape.
A pragmatic sequence for a team of systems developers (systemutvecklare) looks like this:
- Make the monolith modular first. Define module boundaries, move code behind interfaces and stop modules from reading each other's tables. This step alone often fixes the delivery problem.
- Measure where it hurts. Look at which modules change most often, which slow down releases and which have different scaling needs.
- Extract the module with the clearest boundary and the strongest reason. Give it its own data store and an API, and route traffic to it.
- Build the platform as you need it. Add tracing, central logging and a deployment pipeline before the second service, not after the tenth.
- Review after each extraction. If releases are not faster or incidents easier to handle, stop and reconsider.
Gradual extraction is closely tied to managing old code. If your monolith is also carrying years of shortcuts, read our guide on technical debt and when to modernise before you split anything.
Keep reading
From our work
Client Case: Lea BankLea Bank rebuilt its digital platform with Strapi, React, GrowthBook, GA4, and BigQuery to improve SEO, A/B testing, and marketing autonomy.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Are microservices better than a monolith?
Neither is better in general. Microservices help when several teams need to deploy independently and parts of the system scale differently, but they add platform, monitoring and data-consistency work. A monolith, especially a modular one, is usually faster and cheaper for one or a few teams. The better choice is the one that removes your actual bottleneck at a cost you can carry.
Do we need Kubernetes to run microservices?
No. Kubernetes is a common platform for running many containerised services, but it is not required. Small numbers of services run well on managed container services or application hosting from the major cloud providers. Kubernetes becomes worth its operational cost when you run many services and need consistent deployment, scaling and self-healing across them, and when someone on the team owns the platform.
What is a modular monolith?
A modular monolith is an application deployed as one unit but divided internally into modules with clear interfaces and their own data. Teams can own modules and work in parallel, and modules can later be extracted into services if needed. It gives much of the structure of a service architecture without network calls, distributed transactions and many deployment pipelines.
How many developers do you need before microservices make sense?
There is no fixed number. The signal is coordination, not headcount: when several teams regularly wait for each other's releases, or one part of the system needs different scaling or availability, independent services start to pay off. One team of five to eight developers rarely gains enough to cover the extra operational work.
