10
May
Containers vs. Hypervisors: Choosing the Best Virtualisation Technology
Choosing a virtualisation solution isn't always easy. The good news is you have many choices to pick from. The bad news is, well, pretty much the same thing. You'll find tons of options for Linux, most of which break down to hypervisor or container-based virtualisation. Not sure which is which? We'll break it down.
Container based virtualisation
Containers are the products of operating system virtualisation. They provide a lightweight virtual environment that groups and isolates a set of processes and resources such as memory, CPU, disk, etc., from the host and any other containers. Although both are forms of virtualisation, hypervisors virtualise on a hardware level while containers achieve this on an operating system level- by sharing the base operating system’s kernel. They further abstract VMs to facilitate isolation of resources to support different processes concurrently.
Benefits of Container based virtualisation
Since containers sit on the same operating system kernel, they are lighter and smaller compared to hypervisors. A base operating system can therefore support containers more efficiently and effectively than hypervisors. This means that they can run on lower spec hardware than hypervisors, which often require extensive, high performance supporting hardware.
By isolating application environments, containers achieve better resource utilisation than hypervisors. Each application uses its own set of resources without affecting the overall performance of the server. They are therefore ideal for enterprises which concurrently run multiple processes on single servers.
Which solution is right for you? That depends a lot on your workload, hardware and environment. In some cases, you could go either way, and in other cases there's a clear winner between hypervisor and container-based virtualisation. In some cases, it may even make sense to deploy both, though that can become more complex in terms of finding management tools that work well with all the options.
The right type of virtualisation depends heavily on the operating systems that you'll be deploying as well as the types of workloads that you need to run. To some extent it's also dependent on hardware, though this is mostly a major factor when working with older (by server-room standards) machines that don't support hardware-assisted virtualisation. If you're not working with hardware that supports virtualisation extensions, that will limit your options somewhat.
Hypervisor virtualisation
Hypervisor virtualisation mechanism emulates the hardware, you can run any operating system on top of any other, Windows on Linux, or the other way around. Both the guest operating system and the host operating system run with their own kernel. Hypervisors based virtualisation tries to achieve the same goals through a different strategy- instead of simply sharing the underlying hardware resources, hypervisors emulate them on top of existing virtual and physical hardware. An operating system is then created to manage these resources, hence making it OS agnostic. In other words, with a windows system based hypervisor running on underlying physical hardware, you can create another system running on virtual resources and install Linux on it. The vice-versa could also be implemented.
The base operating system achieves this by modifying underlying physical hardware resources to fit the processing requirements of the guest operating system. Hypervisors manage the process by controlling the amount of resources allocated to guest operating systems. Since they sit between the actual physical hardware and guest operating systems, hypervisors are also referred to as virtual machine monitors or VVMS.
Since both containers and hypervisors have their set of benefits and drawbacks, the most sustainable architectures include both systems in their framework. By leveraging both according to their features and application suitability, you stand to benefit more compared to an organisation that focuses on just one of them. Containers are therefore not replacing hypervisors, but rather complementing their capabilities.
Benefits of Hypervisor virtualisation
For one thing, it will allow a better use of hardware to get more computing work done all at the same time. Even users at home can benefit from this type of technology, as it will allow them to run more than one operating system on top of a single host computer, ensuring that lack of backwards compatibility of cross-platform support is never a problem. For businesses, it can help maximise the budget which can then be spent on much more important things.
There is so much to do with hypervisor these days that is why making use of it today can be a huge benefit anyway you look at it.
Drawbacks of Hypervisor virtualisation
Although simulations are intended to optimise resource utilisation, hypervisors largely slow down their servers. It occurs due to several CPU and memory managers within the guest and host operating systems. The best way to boost performance in such cases is through paravirtualised hardware, where a new driver and virtual device is built for the guest.
Hypervisors also fail in providing for complete process isolation. As a result, all VM resources are directed to a single process. They are therefore unsuitable for extensive app testing, a process which requires individual process isolation to prevent the transmission of bugs to other processes.
Drawbacks of Container based virtualisation
Although they are widely considered as a revolution to cloud computing, containers have their own set of drawbacks. First, they can only run on cgroups and namespaces (Cgroups = limits how much you can use; namespaces = limits what you can see and therefore use), both of which are Linux kernel features. That makes them incompatible with other operating systems like Windows and Mac OS. Due to this huge disadvantage, both Windows and Mac OS are reportedly developing systems of integrating containers within their servers.
Secondly, containers are less secure and more vulnerable compared to hypervisors. By accessing only a couple of namespaces through libcontainers and leaving out the rest of the kernel subsystems, containers make it easy for hackers to crack through their operating systems.
