Containers & Kubernetes

In one line

A container freezes an application plus every dependency into one runnable image ("works on my machine" becomes "works everywhere"); Kubernetes runs many containers across many machines, restarting, scaling and routing automatically.

The problem it solves

Two problems, two layers. First, "works on my machine" — an app that runs in dev but breaks in production because the environment differs. A container packages the app with its dependencies, so it runs identically everywhere. Second, running many of them reliably — restarting crashes, scaling under load, routing traffic, rolling out updates. That's Kubernetes.

Containers

Containers share the host kernel but live in isolated namespaces — far lighter than VMs, started in milliseconds, built from layered images (Docker is the household name). The image is immutable and portable: build once, run anywhere.

Kubernetes (orchestration)

Kubernetes adds a control plane. You declare desired state — "three replicas of the FHIR service, this much memory" — and controllers reconcile reality toward it:

• Self-healing — a crashed pod is restarted; a dead node's pods are rescheduled.
• Rolling deployments — update with no downtime, roll back on failure.
• Service discovery & load balancing, secret/config management, autoscaling.

The cost is real operational complexity; managed offerings (EKS/AKS/GKE) and simpler platforms exist precisely because of it.

Where it shows up in digital health

Hospital integration engines, FHIR servers, and AI inference services increasingly ship as containers; national-scale platforms run on orchestrators; and per-user lab sandboxes (this platform's phase-2 question) weigh containers against WASM for isolation.

The sizing rule

Same discipline as elsewhere: Kubernetes earns its weight at fleet scale — a single Next.js app does not need it. Reach for containers early (portability is cheap); reach for full Kubernetes only when you're running a fleet.

Common pitfalls

• Adopting Kubernetes prematurely — its complexity can sink a small team; start simpler.
• Treating containers as VMs — they're immutable and disposable; don't SSH in and mutate.
• Secrets in images — never bake credentials into a layer; use secret management.

Key takeaways

• A container = app + dependencies in one portable, immutable image (run anywhere).
• Kubernetes declaratively runs fleets: self-healing, scaling, rolling updates, routing.
• Powerful but operationally heavy — managed services exist for a reason.
• Containers early for portability; Kubernetes only at fleet scale.