Why Container Runtimes Deserve More Attention
Now that the battle for container orchestration has waned, what will be the next big front in the container ecosystem? My bet is on container runtimes, which are arguably the one part of containerized application stacks where no de facto frontrunner has emerged.
If you look back on what has happened in the container ecosystem during the past five years or so, you’ll notice that there was a lot of competition for some time in a few key areas:
- Orchestration, with Kubernetes vying against Docker Swarm, Marathon and other solutions. As noted above, Kubernetes seemingly has won.
- Approaches to persistent data storage. There were a variety of solutions on this front. As an extension of Kubernetes’s popularity, the Kubernetes approach basically won.
- Registries. Here, Docker Hub competed with alternatives such as Quay. Docker Hub won out.
- Host operating systems. Early on, everyone was hosting containers using a purpose-built Linux distribution, such as Alpine Linux. Now, you typically use whichever host OS your Kubernetes distribution wants you to use (meaning RHEL if you use OpenShift, Ubuntu if you use Canonical Kubernetes, etc.).
For the most part, the competition that prevailed in these areas is now over. No one solution has achieved complete market saturation in any of these niches, but there are clear front-runners that have become so predominant that it’s hard to imagine things changing for the foreseeable future.
The Battle for Container Runtimes
You can’t say the same for container runtimes, or the execution engine that actually runs containers.
There remains a long list of widely used container runtimes, including containerd, CRIO-O, rkt and Kata, to name just the most popular ones. I don’t think you could argue that any of these solutions has emerged as the clear leader at this point.
At first glance, the competition within the space surrounding container runtimes may not actually matter. For the most part, container runtimes are interchangeable. They all do the same basic thing. Kubernetes supports all the mainstream runtimes. Generally speaking, you don’t need to modify your container images or other configurations to switch from one runtime to another.
But when you dive below the surface, container runtimes vary significantly. They are architecturally different—rkt has no central daemon, for example, which makes it very different from containerd. And Kata enforces hardware-level isolation, which is a huge feature that other runtimes lack.
I’m surprised that more is not made of these differences. Perhaps that’s because containerd has done such a good job of pitching itself as the “industry standard” runtime that everyone believes it, even though there are so many competing runtimes out there that also adhere to industry standards.
Perhaps it’s also because Rkt has more or less been neglected since Red Hat’s acquisition of CoreOS, and because Kata remains so new.
Either way, what’s clear is container runtimes occupy a diverse and dynamic field—a characteristic that sets this niche apart from other segments of the container ecosystem. If you’re wondering where the next battle for dominance of containerized application stacks will take place, I think runtimes are a safe bet, despite how little attention they have received to date.