Chapter 2 is the least technical chapter in the book and, in my opinion, the most valuable. Before any proxy or saga, Newman asks whether you should migrate at all, what you are actually trying to achieve, and how you will know you are getting there. Much of it is about people: persuading colleagues, changing team responsibilities, and admitting when a plan is not working.

If you only have time for one chapter before a migration kickoff meeting, read this one.

Chapter 2 in the book.

Key ideas

Microservices are not the goal

The chapter opens with a blunt claim: nobody wins by having microservices. Adopting them should be a deliberate decision aimed at an outcome you cannot reach with the current architecture. Without a clear outcome you cannot prioritise, you drift into analysis paralysis, or you copy a famous company because it worked for them.

Newman's three questions are the core tool, and they work as a checklist for any large technical change:

1. What are you hoping to achieve?
   An outcome the business cares about, described as a benefit to users.
2. Have you considered alternatives?
   Cheaper, more boring options that might get the same result.
3. How will you know if the transition is working?
   Measures and checkpoints agreed before you start.

He reports that asking these questions alone has been enough for some organisations to reconsider.

Every reason has a cheaper alternative to try first

The chapter walks through the common reasons for adopting microservices and, for each one, other ways to get the same benefit. This is the part I would put in front of any team that has already decided the answer:

Reason given Alternatives the book suggests trying
Team autonomy Give teams ownership of parts of the codebase, self-service infrastructure, a modular monolith
Faster time to market Map the whole path to production first; the bottleneck is often outside development
Cost-effective scaling Bigger machines, more copies of the monolith behind a load balancer
Robustness Redundant instances across failure zones, fewer manual processes
More developers A modular monolith with team-owned modules, accepting some release coordination
New technology Other languages on the same runtime, or replacing the stack incrementally

Reuse gets special treatment. Newman argues it is a poor goal because it is only ever a means to something else, usually speed, and optimising for reuse can slow you down when the reusable thing belongs to another team. Measure the outcome you want, not reuse.

He also separates robustness from resilience: robustness is handling the failures you expected, resilience is an organisation's ability to adapt to the ones you did not. Splitting a system into more processes gives you options for robustness, but it also increases the surface area for failure.

When microservices are a bad idea

Four situations get a clear warning:

  • Unclear domain. Wrong boundaries are expensive to move across services. The ThoughtWorks SnapCI team split too early, merged everything back into one application, and only split again once the domain had settled.
  • Startups. Before product and market fit, the domain shifts constantly. Microservices solve problems you have after initial success, and it is easier to split a working brownfield system than to guess boundaries up front.
  • Customer-installed software. You push operational complexity onto customers who cannot be expected to run many processes or a cluster.
  • No good reason. Doing it because everyone else does is the biggest warning sign of all.

When several goals are in play, Newman suggests ranking them explicitly, for example with sliders where raising one priority forces another down, so secondary wishes such as trying a new language do not take over the primary goal.

Bringing people along

Much of the chapter adapts Kotter's eight-step change model to an architecture migration. I find the early steps the most useful at team scale: create urgency around the problem rather than around microservices, find a guiding coalition that includes people outside engineering (because trade-offs such as stale cached data affect users), and agree on a vision that is ambitious but believable. Later steps are about removing obstacles, delivering quick wins, building on them, and making the new way of working normal, while leaving room for the next better idea.

On teams, Newman warns against copying another company's structure (the so-called Spotify model, which Spotify itself no longer used) and against announcing that developers now run everything around the clock. His alternative is practical: list every delivery responsibility, map who does it today, draw the target state six to twelve months out, and move responsibilities one at a time with training and support. For skills, he recommends private self-assessments that feed an anonymised team picture.

Start small, keep decisions reversible, and choose with two axes

The strategic heart of the chapter is incremental migration. Extract one or two services, get them into production and used, learn, then decide the next step. A service extraction is not done until it is live, because most of the lessons (tracing, latency, failure modes) only appear in production.

Newman borrows the idea of reversible and irreversible decisions and treats them as a spectrum. Most migration decisions are near the reversible end and can be made quickly by people close to the problem. The expensive ones, like splitting a database or changing a widely used API, deserve more care. The cheapest place to make mistakes is the whiteboard: walk real use cases across your proposed boundaries and look for chatty or circular calls.

To choose where to start, build a rough domain model (Event Storming is his recommended exercise), then rate candidates on two axes: how hard they are to extract, judged partly by inbound dependencies, and how much value extracting them delivers towards your goal. Here is the shape of that exercise with my own example:

                    easy to extract
                          ^
        Certificates      |      Invoicing
        (rarely changes)  |      (changes weekly, few callers)
                          |
  low value <-------------+-------------> high value
                          |
        Admin reports     |      Notifications
                          |      (many callers, hard to cut)
                          v
                    hard to extract

Start in the easy and valuable quadrant, and redraw the picture as you learn, because some easy things turn out hard and the reverse.

Knowing whether it is working

Newman recommends regular checkpoints that cover four things: restate the goal and stop if the business has moved on, review the numbers, ask people how it feels, and decide what to change. Quantitative measures should follow the goal (cycle time and deployment frequency for speed, load tests for scale), with the warning that metrics can be gamed and that some will get worse before they get better. Qualitative feedback matters just as much. Small steps are also the best protection against the sunk cost fallacy, because changing direction after a small bet is cheap.

Reading it in 2026

  • The scepticism has become mainstream. Many teams now default to a well-structured modular monolith and extract services only where a specific pressure (scale, team independence, a different runtime) justifies it. Newman's framing of microservices as a means, with cheaper alternatives listed for every goal, is essentially that position.
  • Measuring delivery. The State of DevOps research that Newman mentions continues as DORA, whose software delivery performance metrics are the usual starting point for the quantitative side of his checkpoints. Pair them with the qualitative questions he lists; the metrics alone miss how the team is coping.
  • Platform engineering. His advice to remove obstacles through self-service provisioning has grown into a discipline. The CNCF Platforms working group published a white paper in April 2023 defining internal platforms and the teams that build them as products for developers.
  • Team design. Team Topologies, which Newman recommends, is still the common vocabulary for stream-aligned and platform teams. His warning against copying a famous organisation's structure applies to it too.
  • Domain discovery. Event Storming remains widely used. Domain Storytelling and context mapping workshops are other options for producing the rough model he describes.

Putting it to work

  1. Write the three questions at the top of your migration proposal and answer them in one paragraph each before anything else.
  2. For the main goal, try at least one of the alternatives in the table above and record what happened.
  3. Rank goals explicitly and name the primary one; park secondary goals that compete with it.
  4. Run a two-hour domain modelling session with non-engineers and place every candidate service on the ease and value axes.
  5. Agree on two numbers and two questions for a monthly checkpoint, and decide in advance what result would make you stop.
  6. Map current delivery responsibilities by team before announcing any change in who deploys or supports what.

Check yourself

  1. What are Newman's three key questions? What are you hoping to achieve, have you considered alternatives, and how will you know if the transition is working?

  2. Why does he consider reuse a poor goal? Reuse is only a means to outcomes like speed or cost, and chasing it can slow you down when shared code is owned by other teams.

  3. Why are startups usually poor candidates? Their domain shifts constantly before product and market fit, so boundaries drawn early are likely to be wrong.

  4. What two axes does he use to choose where to start? Ease of extraction and the value the extraction brings towards the goal.

  5. When is a service extraction finished? Only when the new service is in production and actually being used.

Further reading