Microservices
Also known as: microservice architecture, microservices architecture
Microservices is an architecture style that builds an application as many small, independent services, each handling one business capability and communicating over the network.
Teams can deploy and scale their service without waiting for everyone else. While microservices helped companies like Netflix and Amazon grow fast, they also trade the simplicity of one codebase for the complexity of a distributed system, which many smaller teams have come to regret.
Microservices, explained at three levels
At home
Imagine a restaurant where one chef does everything versus a kitchen with separate stations for grilling, salads, and desserts. Microservices are the stations: each part of an app is handled by its own small team and program.
At work
With microservices, different teams can update their part of an app without waiting for others. A problem in one service, like recommendations, doesn't have to bring down checkout.
At home
Each microservice has its own code and usually its own data. Services talk to each other through APIs or messages. For example, an online store might have separate services for products, carts, payments, and shipping.
At work
Microservices need supporting infrastructure: containers and orchestration, CI/CD for each service, API gateways, service discovery, observability with distributed tracing, and clear ownership. Without these, teams end up with a 'distributed monolith,' all the complexity with none of the independence.
At home
Network calls fail and add delay in ways function calls inside one program don't. In my opinion, the biggest hidden cost is data: keeping information consistent across services that each own their own database is genuinely hard.
At work
Define service boundaries around business domains (domain-driven design helps), avoid shared databases, and use patterns such as sagas for multi-service transactions and asynchronous events to reduce coupling. Many teams now start with a 'modular monolith' and split services out only when team size or scaling needs justify it.
Real-world examples
At home
Aisha noticed that when a streaming service's recommendations broke, she could still play shows. A friend in tech explained that recommendations and playback ran as separate microservices, so one failing didn't take down the other.
At work
Jerome is the CTO of a 12-person Canadian startup that split its app into 20 microservices early on. Debugging took days and deployments were fragile. Merging them back into a modular monolith doubled the team's release speed.
How it compares
| feature | Microservices | Monolith |
|---|---|---|
| Structure | Many small, independent services | One application |
| Deployment | Each service separately | All at once |
| Operational complexity | High | Lower |
| Best fit | Large organizations with many teams | Small teams and early products |
Microservices help many teams move independently, at the price of distributed complexity.
For analysts
Ask how many teams will work on the system before choosing microservices. I'd only split services when teams are actually blocking each other, because the architecture's cost arrives on day one and its benefits arrive at scale.
History & origin
Service-oriented architecture (SOA) promoted reusable services in the 2000s, often with heavy enterprise middleware. Amazon reorganized around internal services in the early 2000s, and Netflix moved to the cloud with hundreds of services after a 2008 database outage. Software architects discussed the term 'microservices' at workshops in 2011 and 2012, and James Lewis and Martin Fowler's 2014 article defined it for a wide audience. Docker and Kubernetes made running many services practical. Then the pendulum swung: in 2023, an Amazon Prime Video team wrote that moving one monitoring system from microservices to a single application cut its infrastructure costs by 90%. In my view, microservices are a solution to organizational scale first, and a technical choice second.