In 30 seconds
- Each service does one job and can be deployed on its own.
- Teams can work and release independently.
- Adds operational complexity; not a default choice.
Benefits and costs
| Benefits | Costs |
|---|---|
| Independent deployment | More moving parts to run and monitor |
| Teams own services end to end | Network calls and partial failures |
| Scale parts separately | Harder data consistency and testing |
James Lewis and Martin Fowler's 2014 article helped define the style.
When they make sense
- Several teams need to release independently
- Parts of the system have very different scaling needs
- The team has solid DevOps and automation
Many teams start with a well-structured monolith and split later.
Services and teams
Conway's Law says systems mirror the communication structure of the organizations that build them. Service boundaries work best when they match team boundaries; see Team Topologies and DDD.
Myth vs reality
Myth · Microservices are always more scalable.
Reality · They can be, at a significant cost in complexity.
Myth · Smaller services are always better.
Reality · Too small leads to chatty, fragile systems.
Myth · Microservices fix a messy monolith.
Reality · A messy monolith often becomes a messy distributed system.
FAQ
What's a modular monolith?
One deployable application with strong internal boundaries.
How big should a service be?
Big enough to own a business capability, small enough for one team.
Do microservices require containers?
No, but containers make them easier to run.