Running your application in containers, and on Kubernetes when it earns it

What this actually solves

Two different problems bring people here, and conflating them is how budgets get wasted.

The first is inconsistency. The application behaves differently on a developer's machine, in staging and in production, because all three have different library versions, different system packages and different configuration edited by hand at different times. Debugging becomes archaeology. Containers solve this directly — the application and everything it depends on are packaged into one image, and that same image runs everywhere with only its configuration changing. Deployments become atomic, too. The container either starts or it does not, instead of leaving a partly-updated directory behind when a copy fails halfway.

The second problem is scale and it is genuinely rarer than the industry's job adverts suggest. It looks like this — a dozen services, several teams releasing independently, load that varies enough that fixed capacity is either wasteful or insufficient, and machines failing often enough that a human cannot be the recovery mechanism. That is what orchestration is for. Kubernetes decides which container runs on which machine, restarts what dies, moves work off a failed node and routes traffic accordingly.

The honest boundary between them matters more than any feature. Containerising is worth doing for almost anyone with a deployment problem. Kubernetes is worth doing when the number of moving parts has outgrown what a person can hold in their head — and not before, because an incompletely understood cluster fails in ways that a single well-configured server never does.

How the work runs

1. Decide, on evidence, which of the two jobs you are buying. Service count, team count, traffic shape, statefulness, and who will operate the result at two in the morning. The output is a recommendation with a reason, and it is frequently a container running on a straightforward server rather than a cluster. One to three days.
2. Containerise the application properly. Multi-stage builds so the shipped image contains the application and not the toolchain that compiled it. A non-root user. A pinned base image rather than a floating tag. Configuration through environment variables. Persistent data taken out of the container entirely — uploads to object storage, sessions to a shared store — because anything written inside a container disappears the moment it is replaced. One to two weeks.
3. Wire the registry and the build. Images built by the pipeline, tagged with the commit hash, scanned for known vulnerabilities in their base layers, and pushed to a registry the deployment target can authenticate against. Three to five days.
4. Stand up the runtime with the parts people skip. Resource requests and limits on every workload. Liveness and readiness probes that check something real rather than returning a fixed success. Ingress and certificates. Secrets from the platform's secret store rather than baked into images. Rolling updates configured so a bad version cannot take every replica down at once. One to four weeks.
5. Break it on purpose, before it breaks on its own. Kill a container mid-request and confirm the traffic moves. Drain a node and confirm the workloads reschedule. Deploy a version that fails its readiness check and confirm the rollout stops instead of replacing the healthy replicas. Then write down what each of those looked like. Three to five days.

What moves the price

How much state the application holds. A stateless service is the straightforward case. An application writing uploads to local disk, holding sessions in memory and building a search index in place has three migrations to complete before containers help at all, and each is application work rather than infrastructure work.

Managed control plane or self-hosted. Managed Kubernetes carries a platform fee and removes the hardest operational responsibilities. Self-hosting removes the fee and hands you control-plane upgrades, certificate rotation and cluster disaster recovery. The second is substantially more work to set up and much more work to live with.

How many services there are. Each service brings its own image, its own probes, its own limits, its own configuration and its own failure modes. The cost scales with the number of independently deployable pieces far more than with the size of any one of them.

What usually goes wrong

Data is written inside the container. Uploaded files, generated PDFs, an SQLite file, a cache directory. Everything works in testing because the container has not been replaced yet. Then the next deploy rolls the pod and the customer's invoices from the past three weeks are gone, with no failure anywhere in the logs because nothing failed — the container did exactly what containers do.

Nothing declares what it needs, so one workload starves the rest. With no resource requests and limits set, the scheduler is packing containers onto nodes blind. One memory leak, or one report job that loads a large result set, consumes the node, and the kernel starts killing processes that had nothing to do with it. Unrelated services go down together and the logs for the actual culprit are the least interesting ones in the incident.

The readiness probe always answers yes. Pointed at a static route that returns success regardless of whether the database connection pool is exhausted or a dependency is unreachable. The cluster's entire safety model depends on that probe telling the truth — it is how traffic is withheld from a pod that is not ready and how a bad rollout is stopped halfway. A probe that cannot fail turns every graceful mechanism in the platform into decoration.