⌘ The Architecture Reference

Ms foundations · Microservices · Beginner

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

🧭 Analogy

You wouldn’t break ground on a twelve-building campus before you knew how many people you’ll hire or what departments you’ll have. You’d rent one flexible floor, learn the shape of the organization, then build. Splitting a system into services before you understand the domain is pouring concrete on guesses.

Microservices are not the goal

“You don’t ‘win’ by having microservices.” They are a means to an outcome your current architecture can’t deliver. Newman asks every organization three questions:

  1. What are you hoping to achieve? (an outcome expressed as an end-user/business benefit)
  2. Have you considered alternatives? (a more boring technique often suffices)
  3. How will you know if the transition is working? (quantitative and qualitative measures)

Two failure mindsets to name out loud: the cargo cult (“if microservices are good for Netflix, they’re good for us”) and the sunk-cost / Concorde fallacy (proceeding because you’re already invested).

The bad-fit contexts

graph TD
Q{"Do you have a clear<br/>business reason?"}
Q -->|No| STOP["Stop — biggest reason NOT to adopt"]
Q -->|Yes| D{"Is the domain<br/>well understood?"}
D -->|No| MONO["Start with a monolith;<br/>learn boundaries first"]
D -->|Yes| S{"Startup still<br/>seeking product/market fit?"}
S -->|Yes| MONO
S -->|No| C{"Customer-installed<br/>& managed software?"}
C -->|Yes| MONO
C -->|No| GO["Microservices may fit —<br/>adopt incrementally"]
  • Unclear domain — getting boundaries wrong is expensive. ThoughtWorks’ SnapCI split too early on a misunderstood domain, merged the services back into a monolith, and re-split successfully a year later. Resolve domain understanding first — a strong reason to start with a monolith.
  • Startups — microservices suit scale-ups (product/market fit found), not true startups still hunting for fit amid huge domain shifts and limited funding. Brownfield is far easier to decompose than greenfield.
  • Customer-installed and managed software — pushes operational complexity onto customers who target well-defined platforms and familiar packaging.
  • Not having a good reason — the biggest one. “Doing microservices just because everyone else is doing it is a terrible idea.”

Try the cheaper alternative first

For almost every benefit there is an easier, non-microservice route Newman urges you to try first:

  • Team autonomy / more developers → a modular monolith with per-module ownership and self-service provisioning.
  • Reduce time to market → a path-to-production modeling exercise first; the bottleneck is often elsewhere (one bank: 6 weeks to deploy but 40+ weeks from idea to start).
  • Scale for load → vertical scaling, horizontal scaling of the monolith behind a load balancer, or a technology that handles load better (none help if the database is the bottleneck).
  • Robustness → multiple monolith copies across failure planes and more reliable infrastructure; investigate that many outages are manual error.
graph LR
G1["Goal: team autonomy"] --> A1["Modular monolith + module ownership"]
G2["Goal: faster delivery"] --> A2["Path-to-production modeling"]
G3["Goal: scale for load"] --> A3["Vertical / horizontal monolith scaling"]
G4["Goal: robustness"] --> A4["Multiple monolith copies"]

⚠️ Conditions, not just reasons

Wells stresses that a good reason is not enough — you also need the conditions: domain understanding, products-not-projects funding, leadership support (the change takes years and real money), teams that want autonomy, processes that enable it (CABs mostly slow you down), and technical maturity (spin up a service in minutes with an automated pipeline). Missing conditions mean “more complexity and no better outcomes.”

Separate the driver from the secondary benefits

Trying to change everything at once — scale and autonomy and a new language — creates confusing priorities and “locks in” microservices even when scaling the monolith would have sufficed. Use a sliders exercise to articulate relative priorities, and classify decisions as reversible (decide fast, delegate) vs irreversible (decide slowly). The vast majority of migration decisions are reversible; the cheapest place to think is the whiteboard.

🔑 Key insight

Default to a monolith (Gall’s Law: complex systems evolve from simple ones that worked). Extract services only as the domain clarifies and a concrete outcome demands it — and remember the improvements you make first (automation, modular boundaries, observability) deliver value even if you never adopt microservices.

See also

When to use it — and when not

✅ Reach for it when

  • You are deciding whether microservices fit your context at all.
  • You want to challenge a 'because everyone else does it' adoption.
  • You need to consider cheaper alternatives before committing.

⛔ Think twice when

  • You have already established a clear, business-aligned reason and the conditions for success.
  • You are mid-migration and need pattern guidance instead.
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-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-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 / 4

1. What does Newman call the single biggest reason NOT to adopt microservices?

Microservices are a means, not an end; without a clear outcome you can't decide what to split first or judge whether it's working.

2. Why are microservices usually a poor fit for a true startup?

Microservices suit scale-ups with product/market fit; getting boundaries wrong in an unfamiliar, fast-changing domain is expensive. Famous 'microservice startups' adopted them later.

3. Why is customer-installed/managed software a bad fit?

Customer software targets well-defined platforms in familiar packaging; expecting customers to operate a distributed system is unrealistic.

4. What is the recommended cheaper alternative to consider first for many goals?

A modular monolith delivers much of the loose-coupling benefit with far less operational complexity and is an equally valid loosely-coupled option per Accelerate.

Comments

Sign in with GitHub to join the discussion.