Published: Last updated:

Microservices

Autonomy Matters More Than Distribution

A microservices architecture structures an application as a collection of small, independently deployable services, each covering a clearly bounded business function. Each service can be independently scaled, deployed, and implemented with its own technology.

Microservices are not an end in themselves. They are an answer to a problem: when a monolith grows too large to be understood and operated by a single team.

Core Principles

  • Single Responsibility: Each service does one thing and does it well.
  • Decentralised Data Management: Each service owns its own database. No shared schema.
  • API-only Communication: Services communicate exclusively via APIs (REST, gRPC, events).
  • Independent Deployability: Changes to one service require no deployment of other services.
  • Design for Failure: Services assume that other services can fail. Resilience is built in.

Anti-Pattern: Distributed Monolith

A distributed monolith is the worst of both worlds: distributed complexity without the autonomy gain.

Microservices Pay Off Under Four Conditions

Microservices make sense when the prerequisites come together:

  1. Independent deployability is required: parts should ship without releasing the rest.
  2. Clear bounded contexts exist to align service boundaries with (DDD, Conway's Law).
  3. The necessary operational maturity is in place (automation, observability, CI/CD) to run distributed systems.
  4. Pressure on team autonomy grows: individual functions with very different scaling or technology requirements, or a strongly diverging deployment cadence.

Focus: Autonomy Through Isolation

The main benefit of microservices is team autonomy. Technical advantages such as independent scaling are secondary.

FAQ

Should we start with microservices?

No. Almost every successful microservices architecture started as a monolith. Start with a well-structured modulith and extract services when the pain is large enough.

How large should a microservice be?

Small enough for a team to fully understand and own it. Large enough to be independently deployable and valuable. The DDD rule of thumb: one service per Bounded Context.

References

Related topics

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.