State of Windows Containers (Post-Ignite)

I talked to a few people at Microsoft Ignite this last week about their thoughts on containers in Windows land. While pretty much everyone agrees that it’s a neat direction, they also agree that it’s been a bit confusing.

I want to just clear a few things up for folks who may still be confused.

“But I’ve been running containers on Windows forever!”

First of all, let’s address the situation prior to Ignite/Windows Server 2016.

We’ve had non-native containers

It’s possible that you have been using Docker on Windows for awhile. But Docker itself isn’t enough to provide container technology but rather container management. So what’s providing the actual container technology?

And wait a second — containers share the kernel of their host. How am I running Linux containers on my Windows host?

Docker on Windows is actually pretty easy to explain. When you install Docker, it downloads a lightweight Linux distribution (alpine Linux) and creates an Alpine Linux VM within Hyper-V


This VM is the actual Docker host and issuing Docker commands via PowerShell is basically just proxying the commands to the VM. If you actually type ‘docker version’ in PowerShell you will see that while the Docker client is running on a Windows platform, the server which the client is interacting with is indeed running on Linux


Most people who are using Docker on Windows do already know this. But for people new to Docker, it is important to note that up until this point you have only been able to use Linux containers on a Linux host VM when on Windows.

This is about developers

Containers share the kernel of their host. This means that only a Windows host can run a Windows container and only a Linux host can run a Linux container. And until now, we have only ever had Linux as the possible container host.

What this also means is that we have never had Windows containers. Containers were not primarily created for systems administrators to save on resource usage — but rather they were primarily created for developers. Yes, there are systems administration implications, but that’s not what containers are all about.

With native Windows containers, .Net developers can now build container apps. This is a game changer for the Windows developer community who were previously excluded from containers altogether.

Windows Container Host Options

Cool, so we can now build Windows containers. But Microsoft has really managed to confuse people with the different container options. Let’s take a quick look at the two options: Windows Server Containers and Hyper-V Containers.

Windows Server Containers

This is actually pretty straightforward in that it’s what people think of when they hear ‘container host’. These are native containers that run in a similar fashion to Linux containers on a Linux host. Some of the characteristics:

  • Requires Windows Server 2016
  • Does not require Hyper-V
  • Containers can be managed via Docker or PowerShell (MS pushes Docker)
  • Can only run Windows containers
  • Host kernel shared with containers
  • Lowest possible overhead

Hyper-V Containers

The Hyper-V Container option is interesting because it allows developers to build their apps as containers and everything acts and looks like a container at the surface. But really, this is just virtualization. I say this because each Hyper-V Container has its own kernel which no other container can use, and this kernel is indeed virtualized. The characteristics of these:

  • Requires Windows Server 2016 OR Windows 10 (Anniversary Update)
  • Does require Hyper-V
  • Containers must be managed via Docker
  • Can only run Windows containers
  • Host kernel not shared with containers
  • More overhead than Windows Server Containers, less than a normal VM
  • Exist due to security concerns over shared Kernel with normal containers

Keep in mind that while these are technically VMs which just run containers, it doesn’t mean they are inefficient. In fact, Hyper-V containers are incredibly efficient relative to a VM. They do not virtualize the entire Windows OS, but rather just what is required to run the containers without utilizing the host kernel. In the words of Microsoft, they are “highly optimized VMs”.


You may wonder about the portability/compatibility between the two. When a developer builds a container, a runtime flag is used to specify which of the two container types it is. That said, Hyper-V containers cannot be run as a native Windows Server Container and vice versa. It needs to be built at runtime for the appropriate platform.

For example, if you are on Windows Server 2016 with both options available and want to run a ‘nanoserver’ Hyper-V Container, you would do

docker run -it --isolation=hyperv nanoserver


Linux developers/sysadmins: You can continue to use Docker on your Linux hosts. You are not able to use Windows Server to host containers without virtualilzation. Not like you were asking for it or expecting it.

.Net developers: Yay, you can finally start building your apps in containers!

Windows sysadmins: be ready to support Windows-based containers. Windows sysadmins will need to learn how to monitor containers, scale them, patch them, etc… Don’t worry, it will be a blast. And if security people whine about it, look into Hyper-V containers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s