What Are You Delegating?

Every abstraction is a trade: it removes work by making decisions for you. Those decisions are still being made — just not by you, and not visibly. For each abstraction: what it genuinely handles, what remains yours, and the escape hatch.

An ORM An HTTP client or SDK A managed database or cloud platform An identity provider An LLM or coding agent A web framework A library function A managed message queue A cache A container runtime and orchestrator

What are you delegating to a container runtime and orchestrator?

Operating Systems

You write

1$ docker build -t api . && kubectl apply -f deploy.yaml

The abstraction handles

✓A reproducible filesystem and environment
✓Isolation via namespaces, limits via cgroups
✓Placement, restarts, rolling deploys, service discovery
✓Health checks and traffic shifting

Still your responsibility

→Memory limits are enforced by the kernel — exceed the cgroup and the process is killed, which looks like a crash with no stack trace
→PID 1 semantics — your process must reap children and handle signals, or zombies and slow shutdowns follow
→Ephemeral filesystems — writes vanish with the container; state belongs elsewhere
→Networking is still networking — DNS, ports, connection limits and NAT all still apply inside the overlay
→Steal time and noisy neighbours — the VM under your container is shared

Know your escape hatch

When: A container restarts "randomly", is slow only sometimes, or cannot connect to something it can resolve.

Drop to: The OS underneath: cgroup events, process states, ss, the network namespace, the node's metrics.

A container is an ordinary process with boundaries drawn around it. Everything you know about processes still applies.

Containers and the OS Memory pressure VM vs container Container networking

Go deeper on this one: