Skip to Content

Production Deployment Patterns

When to use

Ship your containerised app to production. Choose by team and scale: Swarm | Kubernetes (k8s) | ECS/Fargate.

Analogy

production orchestration is the conductor of a symphony: many instances (musicians), autoscaling, healthchecks, rolling deploys.

Data-flow diagram

  Docker Swarm       simple, single-binary; small teams.
  Kubernetes (k8s)   industry standard; steep learning curve.
  AWS ECS            first-party; integrates with ALB, IAM, CloudWatch.
  AWS Fargate        ECS without managing EC2 (serverless containers).
  Nomad              single-binary alternative to k8s.
  Fly.io / Render    PaaS that runs your Dockerfile as-is.

Deep explanation

Production orchestration decides which nodes run which instances, how to scale, how to update without downtime, how to expose traffic, how to handle persistent volumes, how to coordinate secrets. Mainstream choices: Kubernetes (k8s) for most production; AWS ECS/Fargate for AWS-heavy; Docker Swarm for small teams; Fly.io / Render for tiny apps. Rolling updates replace instances in waves; readiness probes gate traffic; liveness probes trigger restart.

Examples

Example 1

docker service create --name web --replicas 4 \
  --publish 80:80 \
  --update-parallelism 1 --update-delay 30s myapp:1.0.0

creates a 4-replica Swarm service; rolling update changes one replica every 30s.

Example 2

# k8s deployment.yaml (abbreviated)
apiVersion: apps/v1
kind: Deployment
metadata: {name: web}
spec:
  replicas: 4
  template:
    spec:
      containers:
      - name: web
        image: 123.dkr.ecr.us-east-1.amazonaws.com/myapp:1.0.0
        readinessProbe: {httpGet: {path: /healthz, port: 8080}}
        livenessProbe:  {httpGet: {path: /healthz, port: 8080}}

k8s Deployment with 4 replicas, readiness/liveness probes, pinned registry image.

Example 3

aws ecs register-task-definition --family web \
  --container-definitions file://task.json
aws ecs create-service --cluster prod --service-name web \
  --task-definition web --desired-count 4 --launch-type Fargate

registers ECS task def; creates service with 4 Fargate tasks - no EC2 to manage.

Common mistake

No readiness probe (new pods serve 500s during boot). Not pinning image tags (rolling deploy with latest -> unpredictable). Single-replica deployment (downtime on update).

Key takeaway

Pick orchestration matching team: k8s for power + portability; ECS/Fargate for AWS + simplicity; PaaS for tiny side-projects. Always: pinned tags, readiness probes, >= 2 replicas, resource limits, secret manager not ENV.

Production Failure Playbook

Failure scenario 1: rolling-deploy-broke-all-instances

Failure scenario 2: secret-leaked-via-k8s-manifest