Will containers kill VMs? There are no winners in this debate • The Register


Register Debate Reg readers have a reputation for never being short of opinions. It is therefore with more than a little surprise that we must declare our last debate, on the motion Containers will kill virtual machines, it was equality!

1,142 of you voted in the debate, and the vote was split across the board.

JavaScript disabled

Please enable JavaScript to use this feature.

How did we get here?

The debate opened with Timothy Prickett-Morgan, co-editor of our sister publication The next platform, arguing in favor of the motion saying virtual machines took off during the Great Recession, when server spending reached unreasonable levels and server consolidation had an irresistible appeal.

While virtual machines have done away with server bills, they have spawned an era of monolithic applications that are difficult to maintain. Tim lamented that we knew better than to do that before the Great Recession, as shown by the early successes of technologies such as Free BSD Jails and Solaris Zones.

The growing enthusiasm for Docker, then Kubernetes, has restored the rightful reign of containers, and we’ll live happily ever after once they defeat VMs. Tim made the following observation:

Darren Yates, a researcher who just completed a doctorate in machine learning and data science, and who is also a seasoned tech journalist, then opposed the motion.

Darren pointed out that the containers are fragile.

“A compromised container endangers all other containers sharing the host kernel, or those built from the same container image,” he wrote.

Darren also extolled the merits of isolating virtual machines and each other.

Maturity also weighed on Darren’s mind, as VMs have been through the wringer for almost 15 years and come out in great shape. History, he argued, teaches us to never ignore this tempering process. And in the context of the container vs. VM debate, Darren argued that we would do well to use the best of VMs to improve the worst of containers.

Second round

After a few oranges at halftime, the second round of arguments began with yours truly resuming hostilities recalling the conversations about the fate of independent software vendors (ISVs) who need to package their products so that they run on more than a dozen combinations of operating systems, hypervisors, clouds and markets.

ISVs prefer to spend less time and resources on packaging, and more time improving their products. So my sources told me that ISVs will soon be shipping their products in containers, and these future upgrades will require a re-platform effort. At this point, even the organization most hostile to containers will have no choice but to adopt containers, creating an unstoppable snowball.

Chris Mellor, publisher of our sister publication of enterprise storage Blocks and files, brought him home for the No argument.

His article focused on how virtualization works and is so widely adopted that it just won’t be abandoned. Containers are therefore a second stack, yet no IT store likes to run two or more paradigms in parallel.

A compromised container endangers all others sharing the host kernel

Chris concluded that container management tools are an application like any other and can be easily virtualized. He therefore concluded that the containers inside Virtual machines are the future. Chris sees neither winner nor loser – he sees both containers and Virtual machines with a long and useful lifespan.

This conclusion was shared by yours truly and Darren, so maybe our closing session resulted in a tie vote.

Readers speak out

In response to the rants of our writers, readers have made their own thoughtful contributions.

“The problem Docker solves is that people have largely forgotten to teach good package management. Coming from a Unixy environment, it hardly seems credible ”, commented a reader named Sed Gawk.

Sed had just started, offering this observation on today’s youth:

“On the other hand,” he continued, “the container has become a play pit to dump all the problems resulting from the lack of packaging in a semi-standardized format. It’s crap, but allows a decent amount of tools on top of that to support self-service to people, who would never be allowed access in another deployment paradigm.

Katrinab weighed with the idea that “if the only advantage of containers over virtual machines is that they use less system resources, then I don’t think that means containers are the future.”

“The hardware gets more powerful every year. These days that usually means more processor cores rather than running faster, but more processor cores are great for a virtual machine deployment. The overhead for FreeBSD or Linux isn’t that high anyway. Windows is a bit more … and the benefit of being able to restart each VM individually, I think, overcomes that.

Lorribot suggested that the debate may have ignored the real world, as the computing he tends includes “single, self-contained instances with no requirements to scale or expand.” Containers and DevOps, it wrote may be relevant to “those who live in [the] world at the service of the Web.

“But a lot of people who live in a manufacturing / distribution / engineering / creation environment aren’t looking for that sort of thing.” Stability and low latency matter more to Lorribot, who asked:

Spirit Reader Free the lapidary observation that any technology is only as good as its implementer: “Frankly, they’re both as good as the person who set up the environment / the image / whatever.”

“I’ve seen more than my fair share of virtual machines that have the same amount of security concerns as a strainer. The same is true for containers.

“Ultimately, someone has to oversee all of this and periodically run a security scan on them to see what new CVEs have come out.”

We could go on, but you get the idea: there are plenty of good arguments on both sides. So much, perhaps, that this subject could grow into a hardy perennial. Or as a commentator who uses the pseudo Ciaran Put the: “Sounds like the perennial vi-emacs argument.” ®


About Author

Leave A Reply