VMs: Imperfect answers to imperfect problems, but they're all we have

Comment I got into an argument with a friend of mine a little while back. This person abhors containers and virtualization, claims not to understand why anybody should need to use them, and refuses to deploy them in production.

What I took away from this encounter were some valid gripes about the design of modern operating systems and applications. I think these are worth exploring, because they not only help explain why virtualization and containers exist but why they are growing in popularity too.

At the core of why both virtualization and containers exist is that applications and processes in modern operating systems aren't always truly isolated.

If one process has a bug, it can step on resources it shares with another process. Two processes could overwrite each others' files or install incompatible dependencies, causing a conflict. These things happen at the most annoying times.

Of course, we want some process interaction, so that programs can work with each other. However, ideally, software has to be prevented from harming other bits of code. If one application requires a particular library that another program can't work with, there should be some way of resolving this without one of the programs crashing when said library is overwritten by an installer or updater.

Package management can't always help here: configuration files or documents can be inadvertently moved or overwritten well after stuff is installed, and it'll crop up when you least expect or need it. Sometimes it's just easier to pop stuff into their own separate sandboxes rather than try to let everything play together nice.

What kind of sandbox?

Various methods for isolating applications have been around for decades under different names.

The easiest to understand is full virtualization, as used by hypervisors. With full virtualization, emulated hardware environments known as virtual machines (VMs) are created. These VMs contain a complete operating system environment (OSE), as well as the applications running on top of said OS. This offers two key advantages.

Because each VM contains a complete OSE, virtualization allows multiple different OSEs to run on a single physical server. Considering the increasingly heterogeneous nature of modern data centers, this capability means that full virtualization isn't going away any time soon.

Full virtualization also lets applications be completely isolated from one another, though these applications are not isolated from the various processes that make up the OSE in which they operate. This is used by organizations to mitigate the risk of application compromise. If an application or individual OSE is compromised, only that one virtual machine instance is affected. For the compromise to spread beyond one VM, it would have to traverse a network, and network traffic can be segmented and monitored.

Containers

Containers take a different approach. Containers isolate individual applications within a single shared operating system environment. There are numerous different approaches.

Some containerization approaches aim only to perform application isolation. Others aim to perform a more complete process isolation. Some containerization approaches seek only to isolate user-installed applications from one another, others seek to isolate applications even from the background support processes that ship as part of the operating system, and in some cases the lines between containerization and true virtualization are blurred, with containers being able to create entire child OS environments with their own kernels.

The most basic form of containerisation is Change Root (chroot). This lies to the applications about where the root of the file system is and enables a form of app isolation. Chrooted applications can try to spread their tentacles throughout the OSE, placing files in all sorts of different directories. In reality they are confined to creating a series of subdirectories under their primary install directory. The application's storage footprint is bottled, though all the application's processes won't know this.

FreeBSD is other end of the spectrum. FreeBSD tries to sandbox applications more thoroughly, though it doesn't go as far as allowing containers to have their own kernel. In a FreeBSD jail, not only is an application's storage isolated, as with chroot, but collections of processes are also isolated from one another.

This means that processes inside one FreeBSD cell cannot communicate with processes inside another FreeBSD cell. FreeBSD jails also have their own user accounts, including their own administrator accounts. As a result, they are much closer to true virtualization than many of the other containerization approaches.

There's a lot more containerization options out there.

Utopia

So let's get back to my friend. He is very unhappy with containerization and virtualization. He finds them to be kludgy Band-Aids, and they seem to offend him on some deeper ethical level.

He is right about containers and virtual machines being kludgy Band-Aids. They are management systems to seemingly intractable problems. In a perfect world, applications would be perfectly packaged, bug-free, and not step on each others' resources. I don't know how this utopia could possibly be achieved. I've worked in IT my whole life, and I would be taking blind stabs at trying to detail what interprocess communication I wanted to allow and not allow.

I don't know how we get to application isolation while minimising storage footprint without deduplication, and deduplication has CPU overhead that offends the kind of nerds who hate containerization and virtualization.

The easy route for me here would be to simply write off my friend's resistance to virtualization and containerization as magical thinking, but he's not a simple guy, and he's not alone. Debates about all of the above problems go back decades, and involve some of the smartest nerds that have ever lived.

There is also the Unikernel crowd – and their vociferous opponents – who have their own take on what digital utopia looks like.

In the end, I don't really know where along this spectrum my friend's ideology lies.

I'm a systems administrator. As such, I have to deal with the world as it is, and implement the technologies that are available. Those technologies are not perfect. They're inefficient. They're vulnerable. They are designed, built and used by humans who won't always understand the intricacies.

Virtualization and containerization are imperfect answers to an imperfect set of problems, but they're the best tools we currently have available and for that reason, neither of them is going away any time soon, no matter how much my friend – and others like him – rejects or holds out against them. ®

We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.