Microservices
Building one application as many small services that each do one job.
Microservices is a way of structuring software in which an application is split into many small, independent services. An online shop might have one service for users, one for the catalog, one for orders and one for payments. Each runs on its own, usually in its own container, often owns its own database, and talks to the others only through APIs or messages in a queue.
The alternative is a monolith: one program that contains everything and is deployed as a single piece. Monoliths are simpler to build, test and understand, which is why most products start as one. Trouble appears when the code and the team get large: a small change requires redeploying the whole thing, one slow part drags down the rest, and dozens of people step on each other's toes.
Microservices answer that by letting each team own a service, change it and deploy it on its own schedule, and scale only the parts under load. The price is complexity. A function call inside one program becomes a network call that can be slow or fail; a single database transaction becomes coordination across several services; and finding a bug means following a request through many logs. Done without need, it creates a "distributed monolith" with the problems of both. Tools like Kubernetes, load balancers and tracing exist largely to manage this.
Keep in mind
- Each service does one job, can be deployed alone, and usually owns its own data.
- Services talk over the network through APIs or message queues.
- Gains: independent teams, deploys and scaling. Costs: network failures and operational complexity.
- Many teams start with a monolith and split it only when it hurts.
Go deeper
- Microservices, by Martin Fowler and James Lewis
- What are microservices? (AWS)
- Microservices on Wikipedia