Zero→Hero
0/17
Module 3 · Scale & Delivery · Unit 12

Hosting — Containers & Kubernetes

"Docker vs Kubernetes" is a category error worth correcting cleanly. This unit gives you just enough deployment vocabulary to sound credible without going down an ops rabbit hole.

⏱ 30 min Prereq: Unit 09 You'll be able to: talk deployment, orchestration, and autoscaling

By the end of this unit

Containers, briefly

A container packages your app with its dependencies into a portable, isolated unit that runs identically on any host — fixing "works on my machine." Docker is the common tool to build and run them. Containers are lightweight (they share the host kernel) so you can pack many per machine and start them in seconds.

Correct the question "Docker and Kubernetes aren't alternatives. Docker builds and runs a container; Kubernetes orchestrates many containers across a fleet. You containerize with Docker, then use Kubernetes (or ECS, Nomad) to run those containers at scale." This reframe alone signals you know the space.

What orchestration buys you

Once you have dozens of containers across many machines, you need something to manage them. Kubernetes (and managed options like EKS/GKE) provides:

CapabilityWhat it does
Scheduling / bin-packingPlaces containers on nodes with capacity.
Self-healingRestarts crashed containers; reschedules off dead nodes.
Horizontal autoscalingAdds/removes replicas based on CPU/custom metrics (ties to Unit 09).
Service discovery + LBStable virtual addresses; spreads traffic across replicas.
Rolling deploys / rollbackShip new versions gradually; revert on failure — zero downtime.
Config & secretsInject environment per deployment without rebaking images.
Kubernetes cluster (control plane schedules & heals) Node 1▢api ▢api ▢worker Node 2▢api ▢worker ▢cache Node 3▢api ▢worker
You declare "I want 6 API replicas"; the orchestrator decides where they run and keeps that true as nodes fail.

When NOT to reach for Kubernetes

Kubernetes is powerful and complex. For a small service or early stage, a managed platform (a PaaS, serverless functions, or a simple container service like ECS Fargate / Cloud Run) gets you autoscaling and rollouts with far less operational burden. The mature answer in an interview isn't "Kubernetes everything" — it's matching the tool to the scale.

Don't over-rotate on ops Hosting is usually a quick part of a system design answer, not the deep dive. Show you understand containerization + orchestration + autoscaling + zero-downtime deploys, then move back to the data/scale problems where the score lives.

The deployment story in one breath

"Each service is containerized with Docker and runs on Kubernetes (managed, e.g., EKS). I declare desired replicas; the cluster schedules them across nodes, restarts failures, and autoscales on load. Deploys are rolling with automatic rollback. A load balancer / ingress fronts the API pods, and stateless services let me scale horizontally. Stateful pieces (databases, caches) run as managed services or carefully-managed stateful sets."

Quick check
An interviewer asks "Docker or Kubernetes?" The strongest response is:
Complementary. The question conflates two layers. You build and run containers with Docker, then orchestrate them at scale with Kubernetes (or ECS/Nomad). Reframing it correctly is itself the signal the interviewer is after.
Quick check
Which is a core benefit of an orchestrator over running containers by hand?
Declarative desired-state management. You say what you want (N healthy replicas, this version); the orchestrator continuously makes reality match — restarting failures, scaling, and rolling out updates without downtime. It doesn't speed up your code or replace data stores.

Practice before you move on

In two sentences, describe how you'd host the photo app: what's containerized, how it autoscales under a traffic spike, how you deploy a new version safely, and which components you'd run as managed services instead of self-hosting on Kubernetes.

Finished this 30-min unit?