Containers

Definition

A container image bundles the application and its userspace dependencies into an immutable artefact that runs identically wherever the runtime exists. Orchestration schedules those containers onto nodes, restarts them when they fail, and handles networking and rollout.

Two separable benefits, frequently conflated: packaging (the image) and orchestration (the scheduler). The first is nearly always worth it. The second has a real cost threshold.

What the packaging buys

The deployment artefact is the same object that was tested. Dependency drift between environments — the single largest source of "works on my machine" — largely disappears. Rollback is re-deploying a previous image tag, which is fast and reliable.

What orchestration buys, and what it costs

Bought: bin-packing many workloads onto fewer nodes, self-healing, declarative rollouts, horizontal autoscaling, and a common deployment interface across many teams.

Cost: a genuinely large operational surface. Cluster upgrades, networking plugins, ingress, storage classes, RBAC, admission control, resource quotas, and a class of failure — a pod evicted for memory pressure, a node draining mid-request, IP address exhaustion in a subnet — that did not previously exist and that application engineers must learn to recognise.

Industry example

Kubernetes descends directly from Google's internal cluster manager, and it carries that origin's assumptions: many heterogeneous workloads, many teams, a dedicated platform group, and enough scale that bin-packing efficiency is worth real money.

That inheritance explains both its power and its poor fit for small estates. An organisation running six services does not have a bin-packing problem, does not have a multi-tenancy problem, and does not have a platform team — so it pays the full operational cost for benefits proportional to a scale it does not have. Managed container services or a platform-as-a-service deliver most of the value at a fraction of the burden.

Failure scenarios

• No resource requests and limits, so the scheduler cannot pack correctly and one workload starves its neighbours.
• Liveness probes that test dependencies, so a downstream slowdown causes the platform to restart healthy pods and amplify the outage.
• No graceful shutdown handling, so every deployment drops in-flight requests.
• Stateful workloads placed carelessly, discovering that rescheduling a database pod is not the same as rescheduling a stateless one.
• IP exhaustion, where each pod consumes an address and a subnet sized for VMs runs out.

Trade-offs

Containers as packaging: almost always worth it. Orchestration: worth it above a threshold of services, teams and scale, and a substantial and permanent tax below it. The honest question is whether you have a platform team, because without one the cluster becomes everyone's part-time problem.

Interview question

"You have eight services and four engineers. Make the case against Kubernetes, then tell me what would change your mind."