⌘ The Architecture Reference

Ms foundations · Guide · Start here

What Are Microservices?

Independently releasable services modeled around a business domain that own their own data — and why information hiding and independent deployability are the whole game.

Ms foundations Start here ⏱ 5 min read Complete

🧭 Analogy

Think of a department store reorganized into independent specialty shops on one street. Each shop runs its own back room, hires its own staff, and can refurbish without closing its neighbours. Customers still get one shopping experience out front — but no single renovation shuts the whole street down. Microservices apply that to software: many small, self-contained services that you can change and release one at a time.

A working definition

Sam Newman defines microservices as independently releasable services that are modeled around a business domain. A service encapsulates some functionality and exposes it over the network — a REST API, a queue, a topic — and is treated externally as a black box that hides its internal implementation. Most importantly, each microservice encapsulates its own database rather than sharing one. Microservices are a specific, opinionated flavour of service-oriented architecture (SOA), the way Scrum is a specific flavour of Agile.

The intellectual core is information hiding (David Parnas): hide as much as possible inside a component and expose as little as possible, separating what changes easily (internal implementation) from what is hard to change (the external contract). Newman draws each microservice as a hexagon, a nod to Alistair Cockburn’s Hexagonal Architecture.

graph TD
Out["Stable external contract<br/>(REST / events) — hard to change"] --> Svc["Microservice (black box)"]
subgraph Hidden["Hidden inside — free to change"]
  Logic["Internal logic"]
  DB[("Own database")]
end
Svc --- Hidden

The key concepts

  • Independent deployability — the ability and the discipline to change, deploy, and release one microservice without deploying anything else. This is the single most important idea: pursuing it is a forcing function that drives loose coupling and stable contracts.
  • Modeled around a business domain — use techniques like domain-driven design to make each service an end-to-end slice of business functionality, prioritizing cohesion of business capability over cohesion of technology.
  • Owning their own state — avoid shared databases. If a service needs another’s data, it asks. “Don’t share databases unless you really need to.”
  • Size is the least interesting aspect — James Lewis: “a microservice should be as big as my head.” Worry about how many services you can handle and where the boundaries go, not lines of code.
  • Flexibility — “microservices buy you options” (Lewis). They have a cost; adopt incrementally, turning up a dial rather than flipping a switch.

Microservices vs the kinds of monolith

A monolith is a unit of deployment — all functionality shipped together — and it is a valid, sensible default, not a synonym for “legacy.” Newman distinguishes three kinds, plus third-party black boxes.

graph TD
M["Monolith<br/>(unit of deployment)"]
M --> SP["Single-process monolith<br/>all code in one process"]
M --> MM["Modular monolith<br/>one deployable, separate modules"]
M --> DM["Distributed monolith<br/>many services, deployed together"]
SP -->|"good default"| OK["Sensible choice"]
MM -->|"Shopify"| OK
DM -->|"worst of both worlds"| BAD["Avoid"]

The distributed monolith — multiple services that must be released in lockstep — is the trap: it has the disadvantages of a distributed system and of a single-process monolith with the upsides of neither. It emerges precisely when information hiding and cohesion are neglected.

⚠️ The size trap

New teams obsess over how small a service should be. Newman calls size “the least interesting aspect.” Splitting too small multiplies network calls, data duplication, and coordination; splitting in the wrong place couples services. Optimize boundaries for business cohesion, not byte count.

Why now? The enabling ecosystem

Microservices became practical thanks to log aggregation and distributed tracing with correlation IDs (Newman treats log aggregation as a near-prerequisite), containers and Kubernetes, streaming with Kafka, and public cloud / serverless. But Newman cautions strongly against adopting too much new technology at once — bring in tech to solve concrete, observed problems.

🔑 Key insight

Independent deployability is the property you protect at all costs. If you cannot deploy one service without deploying others, you do not have microservices — you have a distributed monolith.

See also

When to use it — and when not

✅ Reach for it when

  • You want to define microservices precisely before deciding whether they fit.
  • You need to distinguish microservices from the several kinds of monolith.
  • You want to understand why independent deployability is the single most important property.
  • You need a shared vocabulary (information hiding, cohesion, coupling) for a boundary discussion.

⛔ Think twice when

  • You are looking for an implementation tutorial — this is conceptual.
  • You have already adopted microservices and need operational guidance.
  • You are choosing between specific technologies (gRPC vs REST, Kafka vs RabbitMQ).
ms-foundationsBenefits and Costs of Microservices

Microservices buy you options — technology heterogeneity, targeted scaling, robustness, organizational alignment — at a real and significant cost in distributed-systems complexity.

ms-foundationsWhen Not to Use Microservices

Microservices are a bad fit for unclear domains, true startups, and customer-installed software — and the biggest reason not to adopt is simply not having a good reason.

ms-decompositionModeling Service Boundaries

Where to draw the lines — using information hiding, coupling/cohesion, the four (or five) types of coupling, and just-enough domain-driven design (aggregates and bounded contexts) to find stable boundaries.

Check your understanding

Score: 0 / 5

1. What is Sam Newman's working definition of a microservice?

Newman defines microservices by independent releasability and business-domain modeling, with each service encapsulating its own state — not by size or technology.

2. Which property does Newman call the single most important idea in the book?

Independent deployability acts as a forcing function that drives loose coupling, stable contracts, and the other benefits.

3. What is a 'distributed monolith'?

A distributed monolith has all the disadvantages of a distributed system and of a single-process monolith, usually because information hiding and cohesion were neglected.

4. What does 'owning their own state' mean for a microservice?

Encapsulation applied to data: hiding the database behind the service boundary limits backward-incompatible changes and preserves independent deployability.

5. Why are microservices described as a specific flavour of SOA?

Newman frames microservices as a specific, opinionated kind of SOA — the way Scrum is a specific kind of Agile. Much of the industry 'failed to do SOA well' because of heavyweight middleware and bad guidance on granularity.

Comments

Sign in with GitHub to join the discussion.