01Side by side
How do they compare?
| Factor | Monolith | Microservices |
|---|---|---|
| Deployment | One unit; every change ships together | Each service ships alone |
| Calls between parts | In-process, fast and reliable | Over the network; can fail or be slow |
| Data | One database, transactions span the app | Data per service; consistency needs patterns such as sagas |
| Scaling | Scale the whole application | Scale just the busy service |
| Testing | Run everything locally | Needs contract tests and integration environments |
| Operations | One thing to monitor | Tracing, service discovery, many pipelines |
| Team fit | One team or a few close teams | Several teams with clear ownership |
| Failure shape | A bug can take down everything | Failures can be contained, or cascade |
02Decision rule
When should you choose microservices?
Choose microservices when at least two of these are true, and say which two before you start.
- 01
Several teams block each other
Teams wait for shared releases or collide in one codebase, and clear business boundaries exist between them.
- 02
Parts scale very differently
One capability needs far more capacity than the rest, and scaling the whole application wastes money.
- 03
Parts need different release rhythms or technology
One area changes daily while another changes yearly, or needs a different runtime.
- 04
You can operate a distributed system
You have tracing, automated deployment and on-call practice, or will fund them.
03The other side
When is a monolith the right answer?
Most legacy monoliths fail on structure, not on being a single deployable. Tangled code gets fixed by clean module boundaries, which a service split does not create by itself.
- One team owns the application and can release it together.
- The boundaries between parts are still unclear. Wrong service boundaries are costly to fix across a network.
- You need strong transactions across the data without extra patterns.
- Operations capacity is thin.
04The middle path
What is a modular monolith?
A modular monolith keeps one deployable unit but enforces clear module boundaries inside it. It gets most of the structural benefit at a fraction of the operating cost, and it makes a later split cheaper, since the seams already exist. See the modular monolith guide.
It is the default we suggest for a legacy application when the main problem is tangled code rather than scale.
05The price
What does a service split cost you?
Calls that were method calls become network calls, so you handle timeouts, retries and partial failure. A transaction across two services is no longer one transaction, which is why teams adopt the saga pattern and accept eventual consistency. Each service needs its own pipeline, monitoring and security. Plan this work before the first split.
06If you do split
How should a monolith be split?
Split along business capabilities, one at a time, starting with a part that has a clear boundary and its own data. Keep the monolith running and route traffic to the new service in steps, so each move is reversible. Avoid a single cutover. The service page on monolith to microservices covers how we run this.
07How Ace8 helps
Decide before you split
Ace8 is the AI-assisted application modernization practice of AceMQ.
The modernization assessment tests your application against the decision rule above and recommends monolith, modular monolith or microservices per application, with a phased plan. To start the work, see monolith to microservices.