Why Are We Still Talking About Containers? Kelsey Hightower's Case for Useful Abstractions

Kelsey Hightower’s ContainerDays London 2026 talk asks a question that can sound deliberately provocative: if containers have been part of mainstream infrastructure for years, why are we still talking about them? The useful answer is not that containers have failed, nor that every workload should be repackaged. It is that a container is still a remarkably effective boundary for distributing software, while the industry keeps confusing the boundary with the whole platform.

The talk’s strongest point is historical and practical. Containers are an operating-system virtualization technique: a process runs with an isolated view of files, processes, users, and other resources, while sharing the host kernel. That model is less magical than the cloud-native vocabulary built around it, but that is precisely why it lasts. It gives developers a repeatable artifact and gives operators a unit they can start, stop, constrain, inspect, and move. The abstraction is useful because it is boring enough to automate.

What changes is the layer above it. Kubernetes, service meshes, registries, policy engines, and managed platforms can add real value, but they also add decisions. A team can spend more time discussing container orchestration than clarifying what the service needs: a process, a port, persistent data, a restart policy, logs, and a trustworthy rollout path. Hightower’s argument is a reminder to keep those needs visible. The container should make the application easier to operate, not become an excuse to adopt a larger control plane without a clear operational payoff.

That distinction helps explain why the same idea appears in very different tools. KubeVirt and the VM-Container Convergence shows how virtual machines and containers can share a Kubernetes control plane without pretending that a VM has become a container. At the other end of the complexity scale, Declarative Containers with systemd and Podman Quadlet treats a container as a service on one Linux host. Both approaches preserve the underlying lesson: choose the boundary that matches the workload and make its lifecycle explicit.

There is also a security caveat. Sharing a kernel is a meaningful trade-off, not a universal replacement for a virtual machine or a stronger isolation boundary. Image provenance, dependency updates, user privileges, Linux capabilities, namespaces, cgroups, and runtime configuration all matter more than whether a deployment is described as cloud native. A container image is not a security review, and a scheduler is not an operational plan. The right question is what must be isolated, who owns the host, and how failure and recovery will be tested.

For practitioners, the talk is most valuable as a corrective to platform fashion. Start with the process and its contract. Package it only as far as reproducibility and ownership require. Add orchestration when the number of services, hosts, teams, or failure modes justifies it. Keep a simpler deployment model when it does not. We are still talking about containers because they remain a useful piece of the stack—but useful abstractions work best when we remember what they abstract, and what they do not.

Watch the full talk: Why are we still talking about containers?.