pixeltrap - Fotolia
Most of the discussions that address the two core technologies for virtualization -- containers and hypervisors -- prominently feature the word versus. This line of thinking wants to pit the two technologies against each other, containers vs. hypervisors, as if there were a battle that might be won by one or the other.
In reality, there's much more to the issue than a contest. It isn't an issue of containers vs. hypervisors. In fact, it's conceivable that containers and hypervisors will coexist and even thrive together.
The great value of containers is that they remove the need for multiple images of the OS, which in hypervisor virtualization is needed in each VM. Clearly, this means much less memory is required for overhead, and so more space is freed up for applications and their data.
The gains in memory space aren't small. Typically, three times the number of instances can be hosted by a server using containers. In some cases, such as with the uniformity of virtual desktops, the gain can reach 10X. Looked at another way, the number of servers needed for a given workload drops significantly. Licensing is also affected. Only one license is needed per server. As applications become part of the shared image, this benefit extends to them, too.
Containers boast performance and security
Containers deliver other benefits. They start faster than a hypervisor instance, mainly because the image doesn't need to be loaded from scratch. Images are more portable and easier to construct, which brings benefits to deployment and agility in operations. Moreover, benchmarks consistently show containers beating hypervisors in performance by as much as 15% in time needed to complete jobs.
With all these plusses, it's reasonable to wonder why, other than industry conservativeness, containers haven't displaced the hypervisor. After all, Docker is providing strong leadership, and the technology is basically sound.
Container technology is fairly new, and is evolving rapidly. The hypervisor approach, on the other hand, is mature and proven. It is hardened for security, with hardware assists in the form of x86 VTx operations that make cross-tenancy hacks almost impossible. There were early concerns that containers were much more vulnerable, with attacks on the underlying OS opening up all instances on a server to compromise.
The result was that containers usually were run on top of a hypervisor. The container instances for each tenant could be segregated into a single VM with hardware protection, preventing cross-tenancy attacks. The drawbacks of the approach are somewhat obvious. Not only is it much more complex, it also involves licenses for hypervisor-related code and more copies of OSes. And performance suffers. And you lose agility -- but at least the instance is secure.
The container ecosystem has risen to the occasion. Thin hypervisors, such as Intel's Clear Containers, are being designed to protect containers and take advantage of the hardware -- without using much space or unduly diminishing performance. Other security improvements, especially in image certification and authentication, mean that containers are now closing the security gap with hypervisors.
Hypervisor developers have not been idle. While initially in denial about the container threat, they eventually began to address the attack points in container technologies. For example, memory minimization is addressed with page deduplication in VMware; this replaces whole memory pages that are duplicates with pointers to a single copy. This is a post-load operation, however, and doesn't address how much quicker containers start up. Still, there are ways to reach parity in operations. For example, memory page deduplication could evolve to a method where an index that's kept with the image is loaded and checked against files already present on a system. This obviates any load operations and drastically speeds deduplication. We tend to compare today's hypervisor against expected future evolutions in containers, forgetting that hypervisor virtualization isn't standing still.
Irrespective of the memory and performance issues between the two choices, there seems to be stratification in use cases between the alternatives. Jobs that scale a lot but don't interact much with each other -- at least directly -- are a good match for containers. Containers, for example, fit the web services model pretty well. Microservices, too, align well with containers, and we can expect a good deal of use in the cloud.
When it comes to containers vs. hypervisors, hypervisors are a better fit for big, monolithic apps. Network and storage structures around the app can be better controlled, and because these larger apps are often mission-critical, saving space and boot time aren't major considerations -- especially when compared with potential downtime or security breaches.
Scientific computing, which entered the virtualization realm just a few years ago, has dramatically boosted productivity. The tools are often customized, though, and they cater to big jobs.
As for the economic issues involved, app and OS licensing approaches need to evolve so that all parties find virtualization affordable, regardless of which method of virtualization is chosen. Per-instance-minute billing may become the norm.
With a robust ecosystem and large installed base, hypervisors will remain important contributors to IT operations. In the battle of containers vs. hypervisors, containers will become the clear winners only if hypervisor designers don't respond. That's most unlikely. In fact, the probable future path looks to be a convergence of hypervisor and container technologies, at least in features and benefits. IT shops that are already heavily invested in hypervisor infrastructure may wish to continue using the approach, either with streamlined hypervisor instances or containers within hypervisor instances. Greenfield installations, on the other hand, likely will head directly to Docker or alternatives. Stratification by app is also likely, as hypervisor virtualization seems to best suit more monolithic apps.
Stop choosing sides between containers and VMs
Fear not -- Docker containers won't supersede the VM
Don't be afraid of virtualization containers
Why use containers when VMs are better for the job?