The world of IT infrastructure is certainly seeing massive changes and an evolution when compared to previous years. We have seen the transition from physical servers through to virtualized server resources. Additionally, software-defined networking and storage have been all the rage in the past couple of years now. Things are continuing to evolve in the realm of how organizations consume and host resources both on-premises and in the cloud. One of the shifts in recent years has been the shift away from full-blown virtual machines to containerized applications.
In the realm of Microsoft’s Windows Server operating system, businesses have a couple of ways to host and consume containers. There are Windows Server containers and the more recently available, Hyper-V containers. Hyper-V containers offer several appealing use cases and advantages when it comes to containers.
In this post, we will take a look at 5 reasons to use Hyper-V containers.
What Are Hyper-V Containers?
Before looking at the 5 reasons to use Hyper-V containers, let’s consider containers in general and what Hyper-V containers add to the mix.
According to Docker, the most prevalent container technology across the industry today, a container is a standard unit of software that bundles up all the code and dependencies needed to run an application, regardless of the environment hosting the container. Theoretically, the container can be moved from one host to another and always have everything needed for the container software to run. Containers, in general, hold many advantages since they are small, lightweight, and are standalone in nature. They include the code, runtime, system tools, system libraries and settings needed for the software.
Compared to a full-blown virtual machine, containers are more efficient as they virtualize the operating system instead of hardware. From a software footprint standpoint, containers are much smaller. Additionally, from a software development standpoint, applications generally rely on certain dependencies to run. With full-blown virtual machines, these dependencies must be considered from the operating system perspective which can be extremely difficult to reproduce exactly from one virtual machine to another. However, these dependencies are part of the container image. So, the environment can be identically replicated from hosting the same container from one host to another.
Windows Server containers are the traditional implementation of containers in the Windows world. However, Microsoft recently unveiled Hyper-V containers in Windows Server 2016 which takes container implementation a step further to be able to implement containers via Hyper-V. This holds advantages over the more traditional Windows Server container approach.
5 Reasons to Use Hyper-V Containers
There are many reasons that organizations can consider in running Hyper-V containers on top of Windows Server. However, let’s take a look at the following 5 reasons to Use Hyper-V containers. Hyper-V Containers provide the following:
- Dedicated Windows kernel
- Applications are not trusted by the host OS
- Applications do not trust each other
- Memory is assigned directly via Hyper-V
- Greater isolation
Let’s see how each of these characteristics provides benefits in running containerized applications.
Dedicated Windows Kernel
In the realm of security and isolation from a Windows kernel perspective, Hyper-V containers provides tremendous benefits. With a traditional implementation of container technology, the containers share the kernel of the host operating system. This is true with Linux as well as Windows containers.
When dealing with a single tenant and only a few applications, this may be acceptable. However, as the security implications of this configuration have under scrutiny, sharing of the host kernel with the guest containers is not desirable. Hyper-V containers create an additional security boundary from the host operating system via a specialized Hyper-V virtual machine. This means the Hyper-V container runs a dedicated Windows kernel.
For MSPs or organizations who want to create additional separation between different containers from different business units, having this additional separation and dedicated Windows kernel running in each Hyper-V container is much more secure than the sharing of the host kernel between the various containers.
Applications Are Not Trusted by the Host OS
Similar in nature to the shared Windows kernel by running traditional Windows containers, traditional container applications imply the host OS shares trust of applications running between the guest containers, since by extension, the containers share the host’s Windows kernel as mentioned above. The entire trust model for applications with traditional Windows Server containers is shared between hosts and guest containers.
With Hyper-V containers, the application trust is contained to the Hyper-V container and not with the host or other guest containers running on the Windows Server host. From a security and isolation perspective, this is much more desirable since the trust for a set of applications or prerequisites only extends within the Hyper-V container and not between containers or the host.
Applications Do Not Trust Each Other
Hyper-V container applications borders are again in the boundaries of the Hyper-V container and not between any other container or host. Again, strict isolation boundaries are in place with Hyper-V containers that help to ensure application trust does not leak between containers or between containers and the Windows Server host.
Memory is Assigned Directly by Hyper-V
In the traditional implementation of Windows Server containers, memory is shared between the container(s) and the Windows Server host. However, with Hyper-V containers, Hyper-V assigns memory to the specialized Hyper-V VM running the container. The memory management capabilities made possible by Hyper-V is a much more effective way to manage memory between the Hyper-V containers and also ensures memory is assigned and dedicated specifically to a particular Hyper-V container.
If there is a “common theme of advantage” between traditional Windows Server containers and Hyper-V containers, it is greater isolation.
In the realm of Windows Server containers, there are two types of isolation – process isolation and Hyper-V isolation.
- Process isolation is the type of isolation that is enacted in the traditional container implementation such as in the Linux container world and traditional Windows Server containers
- Hyper-V isolation – A specialized virtual machine runs each container inside Hyper-V and provides kernel level isolation between the containers themselves and the containers and host
After a year of “processor meltdowns” and other security vulnerabilities that have opened everyone’s eyes the danger of moving laterally across environments and between traditional security boundaries, having more security boundaries and isolation is key. Since Hyper-V containers provide much greater isolation between running containers, this allows for a much-improved security stance when compared to simply running traditional Windows Server containers.
Container technology is here to stay. In fact, many organizations are looking at how they can run business-critical applications as microservices running in containers instead of monolithic apps running in full-blown virtual machines. The immutable infrastructure methodology is much easier carried out using containers as opposed to full virtual machines running traditional monolithic applications.
In the world of Windows Server containers, traditional Windows Server containers are less desirable from a security perspective than Hyper-V containers. This is due to the much greater security boundaries and isolation possible with Hyper-V containers as opposed to Windows Server containers. When using the latest and greatest container features with Windows Server 2016 and higher, organizations will certainly want to consider utilizing Hyper-V containers for hosting business-critical services and applications for their microservice architectures of today and tomorrow.