I spent the end of last week at Monki Gras, a London developer conference focused on the craft of software development. It’s a fascinating event, and this year focused on how to package software.

Not surprising, many of the speakers talked about the role of containers in devops and continuous delivery. But there was a general misconception of Windows’ support for containers, generally characterized as support for running in Linux VMs.

That’s not true: Windows has its own container technologies, building on Docker but giving it a uniquely Microsoft spin. That’s probably the source of the confusion, with Windows 10 adding support for a Linux subsystem and Microsoft adding Docker tools to Windows Server 2016 around the same time. Both are part of Microsoft’s approach to cloud-native application development, which is a key element of its Azure platform going forward.

Microsoft’s commitment to containers, one of the more important cross-industry developments of the last few years, shouldn’t be surprising. Perhaps best thought of as a way of encapsulating an entire user land of processes and namespaces to isolate it from other instances running on the same server, containers have rapidly become a key component of devops and continuous-integration implementations. Microsoft has been a quick adopter of these approaches internally, and as always, its tools reflect how Redmond is using software and how it builds applications.

, Windows has its own container technology. It’s based around the popular open source Docker container service, but it adds support for using the PowerShell command line and for additional isolation with the combination of the and Hyper-V Containers.

makes the most sense because there’s a OneGet PowerShell module that installs both the Windows containers feature and Docker, with only one reboot needed to get started. (You’ll also need to enable Hyper-V virtualization if you want to use Hyper-V containers.)

There’s a surprising amount of enthusiasm for Windows containers from both developers and ops teams; Microsoft has reported more than 1 million downloads of the base Windows images from Docker’s Hub container library since Windows Server 2016 went into general availability.

Building and deploying containers on Windows

Containers aren’t only a server tool; the Professional and Enterprise versions of Windows 10 Anniversary Edition also support containers. You’ll need to enable them from the Windows Features dialog, but once they’re enabled you can install and manage Windows containers on a development PC using PowerShell. Because Windows 10 only supports Hyper-V containers, you’ll need to install Hyper-V as well.

Once the Windows containers have been enabled, you’ll need to download and install the Docker Engine and Docker client, and install the base images you’ll need to configure for your application.

Microsoft’s suggested base image for new-build Windows containers is Nano Server, its low-footprint cloud-focused server implementation. Nano Server makes a lot of sense as a container base: It’s small and fast, with no UI, so it’s quick to deploy and relatively secure.

One important note: Although you can use it to host runtimes like Node.js, Nano Server is intended to host .Net Core applications, including ASP.Net Core, so you won’t get all the .Net features you’re used to. There’s enough of a difference from the familiar Windows Server that it’s perhaps best to think of Nano Server-hosted Windows containers as a tool for new applications rather than as a host for existing code.

Those differences explain why many businesses are using Windows Server Core as a base image. Although it is larger and takes longer to deploy than Nano Server, Windows Server Core offers support for current Windows SDKs and a full .Net implementation. It’s a lot easier to quickly move existing code to Server Core, giving you the option to, as Lead Program Manager for Windows Server and Hyper-V Containers Taylor Brown calls it, “lift and shift” from existing servers to containers, so they’re deployable wherever you want. Once the application is in a container, developers can decompose it further; for example, moving API connectors to their own Nano Server-based containers to simplify application maintenance.

Container support is being built into Windows tools at the very lowest level, with Windows containers now a deployment target for Visual Studio 2017. You can build and deliver applications as a container, ready for test. Making containers a simple mouse click away is an important step.

With Windows Azure soon to support nested virtualization, the ability to add more isolation in the public cloud will help regulated industries justify a move to both containers and to the cloud.