Microservices Pattern

Immutable Infrastructure

Never patch running instances; build a new image and replace them.

deploy

Detailed Description

This way, what runs in production is exactly the thing your build system built and tested - not a server somebody has since edited.

Going back means deploying the previous image again, rather than trying to remember and undo what you changed on a server.

Never log into a running server to patch it by hand. Build a new image and replace the server - otherwise every machine slowly becomes slightly different.

Pair with GitOps or declarative deployment pipelines so desired state and runtime state stay aligned.

Treat runtime as disposable: build once, promote through environments, and replace predictably.

Visual Diagram

Mutable (old way)
  Server → SSH in → apt update → patch
  (drift: servers become snowflakes)

Immutable (correct)
  Code change → build new Docker image
  → push to registry
  → deploy new pods
  → terminate old pods
  Every deployment is predictable

Tradeoffs

Pros

Predictable deployments, no configuration drift

Cons

Requires strong build and release pipeline

Examples: Docker, Kubernetes, Packer AMIs, GitOps with ArgoCD

Comments

Loading comments...