By the end of the lesson, you can define the microservices architecture, list its characteristics, and along the seven aspects say what the system gains and what it pays for independence.
Why did it come about?
In a large monolith, changes wait for each other: shared release, shared data model, shared process. The microservices style addresses the problem of how many teams can change a large system independently of each other, at their own pace. This is an organisational problem as well, not only a technical one.
What is a microservice?
According to Fowler and Lewis, the style is a suite of small services, each running in its own process, communicating through lightweight mechanisms (often an HTTP resource API), built around business capabilities, and independently deployable by automated machinery. According to the Azure Architecture Center, each service implements a single business capability within a bounded context and has its own data store.
"Micro" does not mean the number of lines or classes. The size of a service follows its responsibility and the work of the team.
The characteristics listed by the article:
componentization via services (the boundary is a service boundary);
organised around business capabilities;
"products, not projects" (the team owns the service throughout its life cycle);
smart endpoints and dumb pipes;
decentralised governance;
decentralised data management;
infrastructure automation;
design for failure;
evolutionary design.
flowchart TB
C["Client"] --> G["Entry point"]
G --> A["Service A"]
G --> B["Service B"]
A --> AD[("Data of A")]
B --> BD[("Data of B")]
A -.->|"message"| B
What does it give?
Independent release: one service can be released and rolled back without the others.
Selective scaling: only the loaded part is increased.
A narrower codebase, smaller responsibility per team.
Technological freedom (but this also has a cost: without shared principles the system becomes fragmented).
A failure boundary: the failure of one service does not necessarily take down the others — if the call chain allows it (3.4).
What does it cost?
Every dimension of independence has a price, and most of the costs stem from the same thing: the local call has become a network call.
Aspect
What changes compared with the monolith?
Coupling
The boundary is a contract; its compatibility has to be managed (6.4)
Deployability
Better, but many services mean many releases and many versions
Scaling
Selective, but every service has its own capacity and operations plan
Data management
Data per service; querying across services is hard
Consistency
Instead of a distributed transaction, mostly eventual consistency and compensation (chapter 5)
Failure handling
Partial failure, timeout, retry, unknown outcome — at every call (chapter 6)
Cost
More releases, observability, automation, skills; in a small team the cost of infrastructure can eat up the benefit of independence
Fowler and Lewis also emphasise: a remote call is more expensive than an in-process one, so remote APIs must be coarser, which is often more awkward; distributed transactions are hard, so services use eventual consistency and compensating operations; moving code across a service boundary is harder; chained synchronous calls multiply downtime.
According to Fowler's "microservice premium", the style comes at a high premium that can significantly slow down development; it is worth considering when the system is already too complex to be managed as a monolith.
Common misconceptions
Statement
Clarification
"A microservice means little code."
The size is determined by responsibility and the team, not the number of lines.
"Every service needs a separate database server."
The point is the ownership boundary; a separate schema is possible too (5.1).
"Microservices are automatically more scalable."
They allow selective scaling, but with operational cost.
"Separate repository = independent service."
Independence is shown by release, data and failure handling.
In short
A microservice is an independently running and deployable service with its own data, shaped by a business capability.
Gain: independent release, selective scaling, team autonomy.
Microservices: Independent Services, Independent Costs
Objectives
By the end of the lesson, you can define the microservices architecture, list its characteristics, and along the seven aspects say what the system gains and what it pays for independence.
Why did it come about?
In a large monolith, changes wait for each other: shared release, shared data model, shared process. The microservices style addresses the problem of how many teams can change a large system independently of each other, at their own pace. This is an organisational problem as well, not only a technical one.
What is a microservice?
According to Fowler and Lewis, the style is a suite of small services, each running in its own process, communicating through lightweight mechanisms (often an HTTP resource API), built around business capabilities, and independently deployable by automated machinery. According to the Azure Architecture Center, each service implements a single business capability within a bounded context and has its own data store.
"Micro" does not mean the number of lines or classes. The size of a service follows its responsibility and the work of the team.
The characteristics listed by the article:
flowchart TB C["Client"] --> G["Entry point"] G --> A["Service A"] G --> B["Service B"] A --> AD[("Data of A")] B --> BD[("Data of B")] A -.->|"message"| BWhat does it give?
What does it cost?
Every dimension of independence has a price, and most of the costs stem from the same thing: the local call has become a network call.
Fowler and Lewis also emphasise: a remote call is more expensive than an in-process one, so remote APIs must be coarser, which is often more awkward; distributed transactions are hard, so services use eventual consistency and compensating operations; moving code across a service boundary is harder; chained synchronous calls multiply downtime.
According to Fowler's "microservice premium", the style comes at a high premium that can significantly slow down development; it is worth considering when the system is already too complex to be managed as a monolith.
Common misconceptions
In short
Review questions
Learning resources