⌘ The Architecture Reference

Ms operations · Microservices · Intermediate

Deployment and Progressive Delivery

Deploying many interdependent services: the five principles of deployment, the options from VMs to FaaS, and progressive delivery — separating deployment from release to control the blast radius.

Ms operations Intermediate ⏱ 4 min read Complete

🧭 Analogy

A theatre does a dress rehearsal (deploy) long before opening night (release), and previews to a small audience before the full house (canary). If a scene flops, they pull it without cancelling the show. Progressive delivery gives software the same separation: get the code on stage quietly, then choose when and to whom it actually goes live.

Build it once

Before deployment comes the build. Continuous integration verifies that new code integrates — compile, run tests — producing a version-controlled artifact built once and only once. Two rules: build the artifact once, and deploy the very artifact you verified (keep environment-specific config outside it). Newman prefers trunk-based development with short-lived branches and feature flags over feature branching, and — on mapping source to builds — favours multirepos (one repo per service: clean build-to-service mapping; cross-repo changes usefully signal wrong boundaries) over the monorepo’s scaling challenges.

The five principles of deployment

graph TD
P["Five principles of deployment"]
P --> I["Isolated execution<br/>ring-fence each instance"]
P --> A["Focus on automation"]
P --> C["Infrastructure as code<br/>Terraform / Pulumi"]
P --> Z["Zero-downtime deployment<br/>rolling / blue-green"]
P --> D["Desired state management<br/>Kubernetes / autoscaling"]
  • Isolated execution — ring-fence each instance’s resources (containers are the default compromise on the isolation/cost spectrum).
  • Focus on automation — REA and Gilt scaled service counts by front-loading tooling.
  • Infrastructure as code — Terraform, Pulumi, CloudFormation. (The client who spent three months rebuilding an environment from emails is the cautionary tale.)
  • Zero-downtime deployment — rolling upgrades, blue-green; the FT’s single biggest delivery-speed win.
  • Desired state management — Kubernetes, autoscaling groups, Nomad; plus GitOps.

The deployment options spectrum

Evaluated against those principles: physical machines → virtual machines → containers (the dominant choice: share the kernel, provision in seconds, weaker isolation than VMs) → PaaS (Heroku as the gold standard — “the smarter the PaaS, the more it goes wrong”) → FaaS (AWS Lambda: pay-per-use, implicit HA, reduced ops, but limited runtime control, execution caps, statelessness, and cold starts).

Newman’s rules of thumb: if it ain’t broke don’t fix it; give up as much control as you’re comfortable with, then a little more; “expect Kubernetes in your future” but it’s not “Kubernetes or bust.”

💡 Let the cloud do the heavy lifting

Wells’s consistent advice: lean on managed services and don’t run your own queues or database clusters. The platform overhead of microservices is real; offloading “undifferentiated heavy lifting” to your provider is one of the biggest levers you have.

Progressive delivery — separate deployment from release

Progressive delivery is “continuous delivery with fine-grained control over the blast radius,” and it rests entirely on separating deployment from release:

graph LR
Build["Build artifact once"] --> Deploy["Deploy to prod<br/>(not live — dark)"]
Deploy --> Canary["Release to 1% (canary)"]
Canary -->|"healthy"| Ramp["Ramp to 100%"]
Canary -->|"breaches SLO"| RB["Auto rollback"]
  • Blue-green — run two production environments, switch traffic.
  • Feature toggles — deploy code dark, flip it on when ready (and to coordinate multi-service rollouts). Cap them and expire them.
  • Canary release — route a subset of users to the new version; auto-roll-back if it breaches thresholds (Netflix’s Spinnaker).
  • Parallel run — run old and new on the same requests and compare (GitHub’s Scientist) — see migration patterns.

⚠️ Don't reach for Kubernetes too early

People adopt Kubernetes (and bespoke platforms) long before they need them, paying enormous complexity for a handful of services. Containerize first, automate desired state, and adopt orchestration only when your current approach strains. “Don’t adopt a Kubernetes-based platform just because you see everyone else doing it.”

🔑 Key insight

High performers deploy more frequently and fail less — because they make each release small and reversible. The mechanism is separating deployment from release so the act of shipping code carries almost no risk.

See also

When to use it — and when not

✅ Reach for it when

  • You are designing how to build, deploy, and release many services.
  • You want to reduce the risk of each release.
  • You are choosing among containers, PaaS, FaaS, and Kubernetes.

⛔ Think twice when

  • You have a single deployable and no independent-release requirement.
  • You need testing strategy rather than deployment mechanics.
ms-decompositionMigration Patterns: Branch by Abstraction & Parallel Run

Beyond the strangler fig — branch by abstraction for functionality deep inside the monolith, parallel run to verify a risky replacement, plus decorating collaborator and change data capture.

ms-operationsTesting Microservices

The test pyramid in a distributed world — why end-to-end tests turn brittle, why consumer-driven contract tests replace them, and how to test safely in production.

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. What is the core idea behind progressive delivery?

Progressive delivery is 'continuous delivery with fine-grained control over the blast radius,' resting on separating deployment from release (blue-green, feature toggles, canary, parallel run).

2. Which is one of Newman's five principles of deployment?

The five are: isolated execution, focus on automation, infrastructure as code, zero-downtime deployment, and desired state management.

3. What two CI rules does Newman stress for build artifacts?

Build once (keeping environment-specific config outside the artifact) and promote the same verified artifact through environments.

4. What is Newman's stance on Kubernetes adoption?

Adopt it when your current approach strains; prefer a fully managed cluster and consider whether FaaS/PaaS would serve better.

Comments

Sign in with GitHub to join the discussion.