Containers in Windows Server 2016: What you need to know

In a story I wrote for Computerworld in January, which was a review of Windows Server 2016 Technical Preview 4, I mentioned Windows Server's new support for Hyper-V containers that had been added to its support for Docker-style containers (present within the beta product since the previous beta milestone release).

However, the presence of two container options has led to a lot of questions. What is the difference between a Docker container and a new Hyper-V container? In which scenarios would you want to use one container solution over the other? Are there separate methods of deploying each of these?

Microsoft has not done a great job of documenting these two container options, and containers themselves are new to the Windows Server platform. Given those two factors, I want to dedicate a whole story to what specific container solutions Windows Server 2016 either provides now in preview form in the available releases, or promises to provide prior to the software's release to manufacturing (RTM) date, most probably in the second half of 2016.

For now, however, your best bet is to read about the different options and hold off on implementing if you can. This is still very early going in the Windows Server containers process and there are still a lot of details to be worked out.


There are two types of containers present in Windows Server 2016 at this time: Windows Server containers and Hyper-V containers. Both support Windows Server only; neither can mix-and-match Linux and/or Unix, for instance.

For lazy administrators like me, let us get the important question out of the way up front: Is one of the two container types more difficult to deploy than the other? The answer is an emphatic no.

The container types execute differently and have different levels of isolation and trust in the hypervisor. But at its core, this is a deployment-time decision made by the owner of the physical machine -- the host owner -- about which type of container will be used, and it is as simple as checking the correct radio button in a wizard. You simply pick between the two at creation time. The decision affects how Windows Server 2016 -- the operating system itself (the hypervisor, sitting at the bottom of all of this stuff, running on the silicon and physical iron) -- isolates and executes the workloads within each container.

So now that you know either container option is the same amount of work for you, how do you intelligently decide between the two? Essentially, it comes down to trust: If you trust the code running within the container, then you would choose a Windows Server (read: traditional, Docker-style) container. If you do not trust the code, or cannot verify it, or it did not come from your internal developers within your own organization, then a Hyper-V container is the way to go. Let's look at each option in detail.

Windows Server containers

Windows Server containers are actually just a portion of the Docker open-source container project, so if you think of a Docker-style container, you will be thinking of a Windows Server container. These containers are essentially a new type of virtual machine that in some ways has less isolation than a traditional virtual machine -- namely because, in a lot of cases, things common to all of the containers running on a host are shared. Among these shared items are operating system files, directories and running services. This is done for greater efficiency, because if you're running three different containers on a host, all with the same version of Windows Server as guests, you need only one copy of the C:\Windows directory at any given time.

This sharing still separates containers from any given application that might run on a host -- but it also reduces overhead and makes containers more lightweight. You have more headroom per server running containers because of this sharing, as opposed to running traditional virtual machines, which are more isolated and do not share anything -- and thus tend to have much more duplication. You also would generally use Windows Server containers when your host and guest are all running the same operating system in order to take advantage of this sharing; as a result, you cannot run a container with Ubuntu Server running on a Windows Server 2016 host. (For that type of workload, you would use traditional virtual machines. Containers wouldn't be appropriate for this. You'd just use VMs, which have been supported in Windows since 2008.)

For what it's worth, right now the two container-image operating systems supported by Windows Server containers are Server Core (Windows without its graphical user interface) and Windows Nano Server, the radically refactored microserver suitable for small microservices-oriented roles. (More on microservices in a bit.)

So how does Docker fit into all of this? Docker provides a "management layer," if you will, of APIs and engines to manage containers -- one that has quickly become an industry standard, quite possibly because Docker itself is open source and widely used. The Docker Hub, available for use by anyone on the Internet, is a true marketplace-style repository of applications that all run within Docker-style containers.

Docker also provides a mental framework that developers can use to come closer to the actual operation of their code and to build entire containers of the environments their code requires to run. Developers essentially build container images, which are then shipped over to operations quite easily, and run essentially as they are as guests on that host. Updates and code fixes can be handled quickly and easily in the same way.

Each of these container images might even work on a very small part of the overall application, which componentizes the solution and makes it easier to work in a microservices-oriented environment. From a big-picture perspective, working with containers increases the accountability for developers to write good code that works exactly within their environment. Developers can no longer write code that works perfectly on their development machines but falls over when deployed on production software -- since they're one and the same, the code has to work in both places. This also decreases the friction between operations and IT -- IT with its pristine server environments and developers who expect certain configurations but often lack the ability or the rationale to change production environments to fit their expectations.

These Docker-style Windows Server containers imply some amount of trust -- either that you have downloaded a trusted application from Docker Hub, or that your internal developers or contract developers provided you with a container running code that you trust. For applications in containers that have trusted code within them, Windows Server containers are recommended and appropriate. The sharing and projection of operating system files should not be an issue for trusted code.

But what happens when there is a need for a little more security, a little more isolation, with less-than fully trusted code or apps?

Hyper-V containers

That is when you start looking at Hyper-V containers, which marry the model of isolation and abstraction from traditional virtual machines with the flexibility, image and easy redeployment formats of Docker-style Windows Server containers, along with the Docker API and management tools that I discussed in the previous section.

Mark Russinovich, CTO for Microsoft Azure, put it this way in a blog entry last year: Hyper-V containers "isolate applications with the guarantees associated with traditional virtualization, but with the ease, image format and management model of Windows Server Containers, including the support of Docker Engine." The difference here is the level of isolation: Hyper-V containers do not directly share operating system files, processes and services with the host. Rather, Windows Server wraps up each small container image in a very low-overhead virtual machine, which achieves the abstraction and trust boundary that a Docker-style Windows Server container does not.

However, this virtual machine is, for all intents and purposes, transparent to the administrator. The container images themselves that run Windows Server understand that they are, in fact, container images and not running on regular unfettered silicon, and thus are able to take advantage of optimizations to the OS that come from that awareness. But even though those container images are more isolated, they are not deployed any differently than Windows Server containers. You still use Docker APIs. You still use the Docker client. You just check a different box, but the container images themselves are built and delivered the same way irrespective of which isolation model you want to use to run them.

The downside of this approach: There is more overhead. Because of the additional isolation, more code and processes are duplicated. There is also the fact that, even though the lightweight virtual machine wrapper for a Hyper-V container is small, it does indeed add a "tax" to the cost of running a container image. So while you can stuff a powerful host full of Docker-style Windows Server containers, Hyper-V containers would be limited to a certain smaller number of containers, all else being equal hardware-wise.

Again, these container images would support only Windows Server. Even though there is isolation, there is still commonality shared between the container images and the host operating system. So if your container images run Linux, another flavor of Unix, BSD or any other alternative operating system, none of these new Windows Server 2016 features will matter to you.

The bottom line: Third-party code, marketplace code or code that otherwise is not completely trusted by any part of your organization should be run in Hyper-V containers. These are also the best choice for multitenant public clouds and other similar environments. You lose nothing but capacity and you gain the security benefits of being more isolated.

Docker containers

Now to prove that branding is always the most difficult part of any technology, allow me to introduce Docker containers. Above, I mentioned that Windows Server containers are a portion of the Docker open-source project. Docker containers are distinct from Windows Server containers. Windows Server containers can use all of the Docker underlying technology, but the existing Docker toolset for managing Docker containers does not work (at least in this release) with Windows Server containers. Nor can Windows Server container-management tools -- at this point, a bunch of PowerShell commands -- do anything of value with Docker containers themselves.

Docker containers are their own specific thing, and while Windows Server containers act like Docker containers in their ability to share but isolate -- which is why I have referred to them as Docker-style Windows Server containers -- they are not Docker containers per se. This may change in the future, particularly in a service pack or the next release of Windows Server, but for now, these three container types, even though they may all be similar, remain distinct concepts. Only two are currently supported by Windows Server.

Where the technology Is today

Right now, container support in Windows Server 2016 is very much a work in progress. There are a lot of moving parts to containers: Removing dependencies on host and operating system files, and specific versions and patch levels; achieving the right isolation and ensuring no code can breach that security and trust boundary; making the developer story right with tools and automation that allow developers to work with containers in their preferred integrated development environment (IDE) and "export" their applications directly to the container; making sure containers can move up and down into the public cloud seamlessly; and more.

In all of these instances, there are still fatal errors and bugs to work through. If containers are crucial to your roadmap of service offerings within your shop, then you may wish to begin testing out the capabilities of Windows Server containers and Hyper-V containers now, and especially check out the PowerShell commands available to enable containers and to manage them on a Windows Server 2016 host.

However, if containers are a nice option but not a must-have for your organization, then my informed recommendation would be to hold off on attempting anything but the most rudimentary exploration using the Technical Preview 4 bits. There are still just too many warts -- including those fatal errors and bugs mentioned earlier -- to really get a cohesive sense of what is happening.

Container support will be an exciting addition to the Windows platform. There is a lot of that story remaining to be written and told.

Copyright © 2016 IDG Communications, Inc.

It’s time to break the ChatGPT habit
Shop Tech Products at Amazon