⌘ The Architecture Reference

Ms foundations · Microservices · Beginner

Benefits 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 foundations Beginner ⏱ 4 min read Complete

🧭 Analogy

Renting a fleet of small vans instead of one big truck lets you send each parcel by the cheapest route, keep delivering when one van breaks down, and swap vehicles independently. But now you run a depot: dispatching, tracking, and coordinating dozens of vehicles that can each get stuck in traffic. Microservices trade the simplicity of the truck for the flexibility — and overhead — of the fleet.

The ledger

Newman is deliberately even-handed: microservices are an architectural choice, not the default. They “buy you options,” and you must decide whether those options are worth a real and significant cost.

graph LR
subgraph Benefits
  B1["Technology heterogeneity"]
  B2["Robustness via bulkheads"]
  B3["Targeted scaling"]
  B4["Independent deployment"]
  B5["Organizational alignment"]
  B6["Composability"]
end
subgraph Costs
  C1["Developer experience"]
  C2["Technology overload"]
  C3["Cost / microservice tax"]
  C4["Monitoring & troubleshooting"]
  C5["Testing complexity"]
  C6["Latency & data consistency"]
end
Benefits -->|"weigh against"| Costs

Advantages

  • Technology heterogeneity — mix languages, runtimes, and data stores, choosing the right tool per domain. The FT trialled a graph database for metadata and moved Java→Go gradually on new services only.
  • Robustness — service boundaries become bulkheads that limit blast radius. (Robustness is not free; spreading work across processes can increase the failure surface.)
  • Targeted scaling — scale only the constrained service and scale the rest down; Gilt ran 450+ services to rightsize each workload.
graph TD
LB["Load balancer"] --> O1["Checkout x8<br/>(hot — scaled up)"]
LB --> O2["Catalog x2"]
LB --> O3["Admin x1<br/>(cold — scaled down)"]
  • Ease of deployment — small, independent releases break the vicious cycle of large, risky, batched monolith deployments.
  • Organizational alignment — small, autonomous, stream-aligned teams own end-to-end slices, scaling the number of developers working without colliding.
  • Composability — functionality can be recombined across new channels (web, mobile, partner APIs).

Costs and pain points

  • Developer experience — you can’t realistically run the whole system locally; resource-heavy runtimes limit how many services run on a laptop.
  • Technology overload — every new tool (Kafka, Kubernetes, a mesh) adds complexity; taking on too much at once is a classic failure mode.
  • Cost — microservices are “a poor choice for an organization primarily concerned with reducing costs.” The platform, tooling, and operations carry a real microservice tax.
  • Monitoring and troubleshooting — “every outage could be more like a murder mystery.” You need observability from day one.
  • Testing — broad end-to-end tests become flaky and slow; you shift toward contract tests and testing in production.
  • Latency and data consistency — in-process calls become network calls; ACID transactions no longer span the whole operation, forcing sagas and eventual consistency.

⚠️ Robustness is not automatic

Splitting a system across processes and machines adds failure modes — lost packets, timeouts, dying nodes. Microservices give you the opportunity for robustness (bulkheads, redundancy), but you must deliberately build timeouts, retries, and circuit breakers. “If robustness relies on humans never making mistakes, you’re in for a rocky ride.”

Where the trade is usually worth it

Newman and Wells agree the strongest reasons are organizational: scaling the number of developers working independently, enabling autonomous teams, isolating compliance/security zones (PII, payments), scaling for load on just the hot part, and flexibility of technology. The medium term is the sweet spot — high up-front investment, then genuine speed.

🔑 Key insight

The honest accounting is: options on one side of the ledger, distributed complexity on the other. If you can name the option you’re buying and it’s worth the tax, proceed incrementally; if you can’t, don’t.

See also

When to use it — and when not

✅ Reach for it when

  • You are building the business case for or against microservices.
  • You need to weigh concrete advantages against concrete pain points.
  • You want to set expectations about the 'microservice tax' before adopting.

⛔ Think twice when

  • Cost reduction is your primary goal — microservices are a poor fit for that.
  • You have not yet defined a clear outcome the architecture must deliver.
ms-foundationsWhat 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-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-operationsResilience: Timeouts, Retries, Circuit Breakers, Bulkheads

Stability patterns for distributed systems — timeouts, retries, bulkheads, circuit breakers, and idempotency — plus the four aspects of resilience and why it's ultimately a people property.

Check your understanding

Score: 0 / 4

1. According to Newman, what is the chief cost of microservices?

Microservices are distributed systems, so they bring latency, partial failure, data-consistency, monitoring, and testing challenges that a single process does not have.

2. Why are microservices a poor choice for an organization primarily concerned with reducing costs?

Newman explicitly lists cost as a pain point; the tooling, platform, and operational burden make microservices a bad choice when the goal is simply spending less.

3. What does 'microservices buy you options' mean (James Lewis)?

Options have value but also a price; you decide whether the flexibility justifies the complexity.

4. Which is a genuine advantage microservices unlock?

You can scale only the constrained services and scale others down — Gilt ran 450+ services to do exactly this. Latency typically gets worse, not better.

Comments

Sign in with GitHub to join the discussion.