What is Windows Server Containers and Hyper-V Containers?

Update – 18/08/2015 [Adding Summary]

Hello All,

First, I would like to thank Microsoft Gulf Technical Community for inviting me to blog on MSDN.

As a Microsoft MVP and Solutions Architect, I would love to share my experiences with you while working with Microsoft Stack of Technologies and my other experiences.

It’s a great platform to share and learn together and any feedbacks and suggestions are most welcome!

A quick disclaimer: The posts/opinions over here are my own views.

Let’s share, learn and have fun!!!

In today’s blog post, we will look at what is Windows Server Containers and Hyper-V Containers.

Microsoft announced last April that they will be adding Windows Server containers and Hyper-V containers for applications in Windows Server 2016 and Nano Server.

WINDOWS SERVER CONTAINERS

Figure 1 - Windows Server Containers (Image Credit: Microsoft)

Windows Server 2016, the next generation of Windows Server which is in Technical Preview 2 now and general availability is next year.  Microsoft Plans to roll out Windows Server Containers, an official name for Windows Server Technology that exist in the Linux world today. This would help us to do file, registry virtualization and network virtualization so that each application/container could have it’s own IP address to provide a layer of isolation so that the container doesn’t have access outside of that Sandbox.

Figure 1, shows what Windows Server Containers would look like with the Docker Engine atop an on-premises server. However, those containers could also run in an Azure IaaS cloud.

One important point to mention that Windows containers will not depend on Docker technology to work. The Linux OS is replaced with Windows Server 2016. While the Dockerized apps of Windows Server Containers won’t be able to run in Linux containers nor vice versa, both Microsoft and Docker see potential in the ability for developers to create distributed applications by coordinating services from Linux containers and Windows containers.

NANO SERVER

Nano Server is stripped-down version of Windows Server 2016. The first benefit is Infrastructure host, that can runs Hyper-V, File Server, Failover Clustering and it will be a great container host as well, that’s Microsoft’s planned introduction of a Nano Server deployment option for Windows Server. Nano Server aims to shrink the size of the code base of Windows Server. While Windows Server Core involved roles and only managed to be somewhat smaller than a full installation of the OS, Microsoft seems to be making much more dramatic progress with Nano Server. The end result in Microsoft’s current estimate is an OS that saves 93 percent to 95 percent of the disk footprint and 92 percent fewer critical bulletins and reboots were cut down by 80 percent comparing to a regular Windows Server, wow this is fantastic!

As with Server Core, a primary motivation is security and uptime. Removing so many components reduces the attack surface and limits the number of patches that need to be applied and, therefore, the number of times a system has to be taken offline for security updates. Like Windows Server Core, Nano Server will be a deployment option rather than an edition of Windows.

A secondary benefit is containers runtime Operating System where actually you can write the next version of Cloud Apps on Nano Server that are using ASP.NET V5. Microsoft is already discussing the possibilities for Nano Server an ideal host for Docker containers. To get a sense of how high priority Microsoft is putting on containers as a design goal for Nano Server, consider that Microsoft is making an OS that is half GB in size of the regular Windows Server version!

Virtual Machines versus Containers

Nano Server should also reduce the delta between VMs and containers. If Nano Server is used as a Guest OS, it’s ultra-slim profile would increase the number of Virtual Machines that can run on the physical host and speed the startup time for VM-based applications.

HYPER-V CONTAINERS

Figure 2 - Hyper-V Containers (Image Credit: Microsoft)

Figure 3 – Nested Hyper-V Containers (Image Credit: Microsoft)

The way to think about Hyper-V Containers is that they offer both OS virtualization (container) and machine virtualization (VM) in a slightly lighter-weight configuration that will have less of a performance hit than a traditional VM. Hyper-V Containers are supposed to be interchangeable with Windows Server Containers. In other words, Windows Server Container applications that are pushed or pulled from the Docker Hub or local repository can be placed in either a regular Windows Server Container or a Hyper-V Container without any modification.

At this point as showing in Figure 2, there would be the server hardware layer at the bottom with Windows Server 2016 OS running on it. Running on Windows Server is the Docker Engine, which would provide the platform for a regular Windows Server Container, the same as in Figure 1. The new piece, the Hyper-V Virtualization, appears to slide in between the Docker Engine and the Windows Server Container.

However in Figure 3, Microsoft is building Nested Virtualization into Hyper-V exactly so they can support running Hyper-V Containers in Virtual Machines, so you can have an Azure Virtual Machine and still taking advantage of running Hyper-V Containers with the isolation that you need for the workload without having to worry about managing physical machines.

In summary, Microsoft is giving us all the options on how to run Windows Containers, we can get a machine where is a physical or virtual really doesn’t matter, and use the Container technology that meets the needs of the workload, so if it needs to be an isolated workload, great run Hyper-V Container, if not Windows Server Container, you pick based on the workload.  

DEVOPS PROCESS

Figure 4 – Dev/Ops Process with Containers (Image Credit: Microsoft)

Containers promise to help bring and close the gap between the developers and operations and enable the faster development lifecycle possibilities that are fueling much of the recent talk about the DevOPs paradigm. so as the developers finish with a revision and push it out to the operations team, it is up to the OPs to figure out how many instances do they need to run. My favorite part is, if 3AM come and there is a bug or mistake in the version that the Dev made, the operation team can now roll back to a previous version of the container. We can keep all versions around, we simply just say version 1 was good and version 2 was bad, let’s go back to version 1 and we will yell at the Dev in the morning .

SUMMARY

Windows Server Containers are great for scenarios where the OS trusts the applications that will be hosted on it, and all the applications also trust each other. In other words, the host OS and applications are within the same trust boundary. That’s true for many multi-container applications, applications that make up a shared service of a larger application, and sometimes applications from the same organization.

Hyper-V Containers take a slightly different approach to containerization. To create more isolation, Hyper-V Containers each have their own copy of the Windows kernel and have memory assigned directly to them, a key requirement of strong isolation. We use Hyper-V for CPU, memory and I/O isolation (like network and storage), delivering the same level of isolation found in Virtual Machines. Like for VMs, the host only exposes a small, constrained interface to the container for communication and sharing of host resources. This very limited sharing means Hyper-V Containers have a bit less efficiency in startup times and density than Windows Server Containers, but the isolation required to allow untrusted and “hostile multi-tenant” applications to run on the same host.

The implications cross the roadmap from Microsoft Azure to Windows Server 2016 to Hyper-V to Nano Server. The technology picture will become clear as we approach the final release of Windows Server 2016. I’ll update this post as details emerge in the coming months.

Thank you for reading!

See you in the next post. Until then, peace… @Charbel