From Monolith to Microservices: When Does It Pay Off?

Microservices are sexy. Everyone talks about them, conference presentations are full of them, and you feel the subtle pressure to "migrate too". But the question is not whether microservices are technically interesting. The question is whether migration is worth it for you right now. And that answer is more often "no" than the hype suggests.

What a monolith actually is

A monolith is an application where all functionality is bundled as a single deployable unit. One build, one deployment, one process. That sounds like a limitation, but it has serious advantages: simplicity in debugging, no network communication between services, transactions are easy to manage, and your codebase is in one place.

Most successful SaaS companies started as monoliths. Basecamp never fully moved away from it. Stack Overflow still runs largely on a single ASP.NET monolith. Shopify only started serious decomposition when they approached hundreds of engineers. A monolith is not a legacy anti-pattern, it is a rational choice for a team that prioritises speed over abstraction.

The problems start when your monolith grows into something that nobody fully understands anymore, where a small change in module A causes unexpected behaviour in module C, and where a deployment takes an hour or longer because everything has to go along.

When microservices are the right step

Microservices solve a specific problem: organisational and technical complexity at scale. They are not a better way to build software, they are a way to scale when a single codebase and a single team no longer work.

The signals that the moment has arrived:

• Deployment pain: you cannot roll out a small change without deploying everything. Every release is a risky operation.
• Team size: multiple teams work on the same codebase and continuously block each other during merges and reviews.
• Scaling needs: one component (e.g. search or reporting) requires ten times more resources than the rest, but you cannot scale it independently.
• Technology heterogeneity: part of your system has fundamentally different requirements where a different language or database fits better.
• Organisation structure: Conway's Law works against you: your architecture reflects an org structure that no longer holds.

None of these signals is sufficient on its own. They are indicators. If three or more apply and they affect you daily, then the conversation about migration makes sense.

The costs of microservices

Microservices bring operational complexity that is often underestimated. What you gain in independence per service, you pay for in overhead:

• Network communication: a call that is a local function call in a monolith becomes an HTTP or gRPC call with latency, timeouts, and retry logic
• Distributed transactions: an ACID transaction across multiple services does not exist. You implement Saga patterns or accept eventual consistency
• Observability: distributed tracing is more complex than logging in a monolith. You need OpenTelemetry, a trace backend, and engineers who understand it
• Deployment coordination: multiple services means multiple deployments, versioning, and compatibility contracts
• Infrastructure costs: each service needs its own compute, health checks, and monitoring. With twenty services, that adds up

A 2023 Gartner study found that organisations that migrated to microservices without a clear problem statement failed to realise the expected benefits within two years in more than 60% of cases. The architecture worked, the problem simply was not there.

Migration strategies

If you do migrate, do it incrementally. A big-bang migration where you rewrite everything in six months is almost always a disaster. The most effective approach:

Strangler Fig Pattern: you build new functionality as separate services and gradually migrate existing functionality. The monolith "suffocates" slowly while new services grow. This is the approach that Shopify, Netflix, and Amazon successfully followed.

Domain-driven decomposition: use Domain-Driven Design to identify boundaries. Bounded contexts in your domain become candidate services. Start with the boundaries that are clear, not the boundaries that are interesting.

Database-first: a shared database between services is not a microservices architecture. Data ownership per service is the foundation. This is also the hardest step, because it requires data migration and adjustment of everything that accesses that data.

Hosting and infrastructure for microservices

Microservices and Kubernetes are not synonymous, but in practice they are almost always used together. Kubernetes provides the orchestration you need to manage dozens of services: scheduling, health checks, scaling, and rolling deployments.

For SaaS companies in the Netherlands, this means that the infrastructure choice for microservices is directly linked to the Kubernetes choice. A managed Kubernetes environment at a Dutch provider offers the foundation without requiring a full-time platform engineer to keep the control plane running.

The most sobering question

Before you start a migration trajectory, one question: what does this concretely solve in the next twelve months? If the answer is vague ("it scales better", "it is more modern"), wait. Migrate when it hurts not to, not because it is interesting to do so. The codebases that last longest are the codebases where engineers know at all times what they are doing and why.