Containers have security problems and flexibility issues. VMs will make them viable

Never bet against a technology that has matured over decades

Register Debate Welcome to the latest Register Debate in which writers discuss technology topics, and you – the reader – choose the winning argument. The format is simple: we propose a motion, the arguments for the motion will run this Monday and Wednesday, and the arguments against on Tuesday and Thursday.

During the week you can cast your vote on which side you support using the embedded poll, choosing whether you're in favor or against the motion. The final score will be announced on Friday, revealing whether the for or against argument was most popular. It's up to our writers to convince you to vote for their side.

This week's motion is: Containers will kill virtual machines

And now, today, arguing AGAINST the motion is DARREN YATES, a research scientist who just completed a PhD in machine learning and data science, and is a veteran technology journalist...

Remember when the PC was going to vanish if Microsoft didn't nail the next release of Windows? It turns out Global PC sales actually rose 4.8% in 2020. Write this off as a pandemic-induced aberration if you want, but as the global workforce gets a taste of working from home and likes it, this sort of ‘aberration’ proves yet again that once a good technology matures, it takes something revolutionary to replace it.

Now, it’s the turn of Virtual Machines (VMs) to supposedly fall at the hands of containers. The only trouble is, VMs go back even further than the PC to the early-1960s, which shows they have enduring value. Containers may well be here to stay, but it doesn’t mean you’ll be saying good-bye to VMs any time soon.

Why? Consider VMs’ versatility, for a start. By lifting the abstraction from the hardware layer up to the app layer, containers can be moved and distributed without worrying about the hardware they’re running on. That same abstraction also allows for deeper server utilisation because you don’t have the setup overheads of a VM with its full-blown guest OS. That much is given.

One compromised container endangers all of the other containers sharing the host kernel

However, abstracting at the app layer reduces versatility, since all containers on the host server are limited to sharing the same host OS kernel. Need to cross-develop for a different hardware platform or require a custom kernel? Containers on their own won’t help.

Abstracting only the lower hardware layer allows VMs to run a mix of different OSes and kernels on the same server. Sure, you lose some versatility in terms of server utilisation by siloing resources, but you gain it back by having greater control over the applications, kernels and OSes your server can run. (Then again, if you use Kubernetes, you might tap KubeVirt to run your VM with your containers, provided your host supports nested virtualisation, but not all do).

In other words, it’s ‘swings and roundabouts’.

However, there’s another important benefit of VMs' lower-level abstraction: security.

Since containers share the resources of the host system, this makes them vulnerable to attack. One compromised container endangers all of the other containers sharing the host kernel, or those built from the same container image. In fact, several attack vectors have been identified by researchers –containers attacking each other, hosts attacked by malicious containers and vice versa. Even containers attacked by its own apps. It sounds like an Aliens movie.

Yet, by incorporating the OS layer in the virtual silo, VMs inherently add an extra barrier that isolates one VM from another, as well as from the host. Should a VM be attacked, that attack ends at the VM border – the system host and other VMs remain unaffected (notwithstanding some nasty side-channel attacks).

Nevertheless, it’s not surprising that one of the more active areas of industry and university research right now is improving container security.

For example, researchers at Cornell University developed X-Containers to improve container isolation and performance by incorporating a Linux-based ‘library’ OS (LibOS), that bundles all of the OS services required by the container application into a library. This is then wrapped around by an exokernel, a lean, low-attack-surface kernel that isolates the containers from each other. Published performance results show good scalability, but an X-Container currently has a larger memory load and is slower to boot than a Docker container (but still faster than a full VM).

In the context of this debate, one of the more interesting solutions lining up to solve the container isolation issue is hypervisor-controlled containers or ‘microVMs’, where each container runs inside a lightweight VM with its own kernel. What you end up with is the security of a VM, but with the fast boot-times and lower resource requirements of a container.

Once a good technology matures, it takes something revolutionary to replace it

Kata Containers are an OCI- and CRI-compliant open-source example evolved from Intel’s Clear Containers platform using QEMU/KVM VMs. Launched in 2018, Kata Containers can also claim some big-name players in their corner, including Apple, Intel and Red Hat. Version 2.2.1 was released just two weeks ago. Based on that alone, there’s not a lot to be gained trying to prove containers will wipe the floor with VMs, because even if you think you’re using a container, there’s a good chance you’re actually using a container inside a VM.

So this doesn’t need to be a fight to the death. Containers complement VMs and where containers fall short, VMs can save the day. So, far from ending up on the scrap heap, VMs are simply evolving to meet the needs of the current ‘as-a-service’ landscape. Just like the PC, VMs have proven themselves over decades – too long for them to disappear now. ®

Cast your vote below. We'll close the poll on Thursday night and publish the final result on Friday. You can track the debate's progress here.

JavaScript Disabled

Please Enable JavaScript to use this feature.