Monolith to Microservices: When It Pays Off and When It Does Not

Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.

Microservices are the modernization option most often chosen for the wrong reason. A large company had success with them, a conference talk made them sound like the grown-up architecture, and a monolith that releases once a month seems like the obvious thing to blame. Sometimes it is. More often the monolith is fine and the problem is a team structure, a missing test suite or a deployment pipeline that takes a day. This post gives you the signs that a move will pay for itself, the signs that it will cost you two years and leave you worse off, and a decision rule you can apply to your own system this week.

What are the signs that microservices will pay off?

• Teams block each other. Three or more teams work in one codebase and a release needs all of them to be ready at once. Release trains, merge freezes and a release manager are the symptoms.
• Parts of the system have different scaling needs. The search function needs ten times the capacity of the invoicing function, and today you scale the whole thing.
• Parts of the system change at very different rates. The pricing engine changes weekly, the ledger changes yearly, and every pricing release risks the ledger.
• A failure in one function takes everything down. A slow report locks the database and nobody can take an order.
• You can run it. There is a platform team, or the budget for one, that can own deployment pipelines, service discovery, monitoring and on-call for a dozen or more services.

What are the signs that it will not?

• One team, fewer than ten engineers. Microservices solve a coordination problem between teams. One team has no such problem, and will spend its time on infrastructure instead of features.
• Releases are painful for reasons that are not architectural. No automated tests, a manual deployment, an environment that differs from production. Microservices make all of these worse, not better.
• Nobody understands the codebase. You cannot split a system into services along boundaries you cannot see. Understand it first, usually by refactoring it into modules.
• The data model is shared everywhere. If every function joins across the same twenty tables, splitting the code leaves you with twelve services and one database, which is a distributed monolith with extra network calls.
• The motive is hiring or fashion. "Engineers want to work on microservices" is a real pressure and a poor reason to spend $600,000 to $2,000,000+ (€520,000 to €1,740,000+, £445,000 to £1,480,000+).

How do the three architectures compare?

The modular monolith is the architecture most mid-sized companies should want and few ask for. It is one deployable unit, which keeps operations simple, with hard internal boundaries between modules, each owning its own tables and exposing an interface. Teams own modules. Tests run per module. And when a module genuinely needs to scale or deploy on its own, it is already shaped like a service and can be extracted in weeks rather than months.

How do you extract a service without a rewrite?

The strangler approach is the same method described in modernizing without the big bang, applied to one function at a time:

1. Pick the function with the clearest boundary and the most pain. Usually something with its own data and a scaling or release problem: search, notifications, reporting, a pricing engine.
2. Put an interface in front of it inside the monolith. Every caller goes through that interface. This step alone often fixes half the pain, and it is the modular monolith move.
3. Give it its own data. The function's tables are separated and nothing else reads them directly. This is the hard part and the one that tells you whether the boundary is real.
4. Move it behind the network. The interface now calls a separate service. Traffic is routed gradually. The old code path stays until the new one has proven itself.
5. Delete the old code. If this step is skipped the monolith never gets smaller.

Each extraction is a project of weeks to a few months, with a visible outcome, which is what keeps sponsorship alive. A program of extractions is how a monolith becomes a handful of services over a year or two without a cutover. The cloud migration post covers the infrastructure side that often runs in parallel.

What does it cost to run microservices?

The build cost gets the attention. The run cost is the surprise. Each service needs a pipeline, monitoring, logging, tracing, secrets, a deployment target and someone on call. A dozen services need a platform: a container orchestrator or a managed equivalent, service discovery, a gateway, centralized observability. That platform needs one to three engineers to own it, which at onshore rates is $200,000 to $600,000 per year (€175,000 to €520,000 per year, £150,000 to £445,000 per year) in people before any cloud bill. For a company with 30 engineers that is a reasonable share. For a company with eight, it is the whole team. What cloud hosting is gives the basics if the terms are new.

What is the decision rule?

Where you land on this rule is a fact about your organization, not about the technology. A monolith is not a failure. It is the right architecture for most systems most of the time, and the companies that get the most from microservices are the ones that waited until they needed them. Technical debt in a monolith is usually a missing module boundary, which is a far cheaper thing to fix than a missing service.

How 7L approaches it

7L International designs, builds and modernizes software end-to-end from hubs in New York, London and Athens, and has supported more than one hundred organizations with systems of every shape. We are not partisans for any architecture. We have built microservice platforms where several teams needed independence, and we have talked clients out of them where one team needed a test suite. Our default for a mid-sized company is a modular monolith with services extracted where the pain is measured, delivered in slices so each one shows a result. The modernization options post places this among the alternatives, and the enterprise software development guide covers the full engagement. If your releases hurt and you are not sure why, tell us how you ship today and we will tell you whether the architecture is the problem.