10 Things You Should Know About Microsoft's Container Strategy

Microsoft’s romance with containers started in last June when it announced support for Docker extensions for Linux VMs running on Azure. Since then Redmond has been steadily making progress with its container strategy. Recently, Microsoft joined Open Container Initiative ( OCI) as the founding member pledging its support for maintaining common container format and runtime. In the latest technical preview of Windows Server 2016, Microsoft finally made native Windows Container technology available to developers and system administrators.

Thanks to media attention and the positive buzz - for many customers, containers are synonymous with Docker. It’s also amply clear that Docker, Inc. open sourced the technology behind containers, and it only runs on Linux. Given these facts, there is confusion in the developer community on Microsoft’s support for container technology. In various blog posts and events, Microsoft highlighted its investments in containers. Microsoft execs didn’t shy away from telling us how much they love Docker and the team behind it. This positioning led to a bit of ambiguity around Microsoft’s container strategy. I have heard developers asking if they can run Linux containers on Windows and vice versa. There is enough confusion around Docker, Windows Containers, and Hyper-V Containers.

I am attempting to demystify Microsoft’s container strategy through a set of data points.

1) Microsoft’s container strategy is not about portability

Let me get this straight. You cannot push a Docker Image from Linux and pull it on a Windows machine to launch the container. The underlying kernel differences between the two operating systems make it extremely hard to make containers portable. In the past, Microsoft did attempt to bring a POSIX compliant UNIX subsystem called Services for Unix. But, that’s a different story. Coming back to containers, you cannot emulate “Package once deploy everywhere” with Microsoft containers. Period.

2) Microsoft has two flavors of containers

Microsoft Windows Server 2016 is capable of running two different varieties of containers called Windows Containers and Hyper-V Containers. Why do we need two types of containers? Because they are designed for separate use cases and scenarios. Technical Preview 3 of Windows Server 2016 only supports Windows Containers. The final version will include both flavors.

3) Windows Containers are lightweight and faster

This flavor retains the advantage of using containers – speed, agility, and performance. It’s a known fact that containers startup much faster than VMs. That’s because they share the kernel of the underlying operating system. Microsoft engineered Windows Server 2016 to support the shared kernel model for containers. Windows Containers rely on the OS for the shared services. This design naturally results in lighter and faster containers. They are very similar to Linux containers. One key takeaway from Windows Containers is that they provide lower isolation levels making it less secure to run heterogeneous workloads. Multiple containers participating in the same application are best suited for Windows Containers.

4) Hyper-V Containers use virtualization

If you think Windows Containers are less secure because of the isolation level, then you should consider Hyper-V Containers. They don’t share the same kernel of the OS and bring strong isolation level that’s similar to virtualization. Behind the scenes, Hyper-V Containers use VMs to run dedicated containers in their own namespace. This architecture results in heavier container sizes and longer startup times. So, when do you need to use them? If you have sensitive workloads that demand strong isolation and security, Hyper-V Containers are the best. In a multi-tenant environment like public clouds, they deliver the best possible security and compliance.

5) Docker Engine exposes both container implementations

Wait! If Microsoft has its own native container implementation, what’s the role of Docker?

Let’s dissect Docker’s architecture.

Docker as a platform has three components:

1. Docker Engine
2. Docker Tools
3. Docker Registry

Docker Engine is the workhorse that does the heavy lifting while exposing the API for the CLI and tools. Docker CLI is the toolchain to manage the lifecycle of containers. Docker Registry is the central location to store images.

Microsoft and Docker worked closely to expose the same API from Windows Containers and Hyper-V Containers. This instantly makes Microsoft’s containers interoperable with the huge ecosystem of Docker. The command line interface is also ported to Windows. Effectively, the partnership resulted in developing a consistent API layer and the client while leaving Microsoft’s engineering team to deal with the core container engine.

6) Docker CLI can be used to control both Microsoft Containers and Linux Containers

The command line interface is available on both Windows 10 and Windows Server 2016 operating systems. Developers and administrators can point the client to a running Docker Engine to take control of it. This means it is possible to manage a Linux container running on a Red Hat server from Windows 10. Since Microsoft decided to make its container engine compatible with Docker Engine, the same client can be used to manage Windows Containers and Hyper-V Containers. Technically, it is also possible to manage Microsoft containers from Ubuntu or OS X as long as the CLI can talk to the remote engine.

7) PowerShell Cmdlets can be used with Microsoft Containers

Apart from using Docker CLI and tools, customers can use their favorite PowerShell environment for automating container management. Microsoft has shipped a set of Cmdlets for dealing with both Windows and Hyper-V Containers. This will be useful for integrating containers with native tools.

8) Azure Service Fabric will orchestrate Windows Containers

Azure Service Fabric is Microsoft’s answer to Kubernetes. It is a platform to design and deploy microservices. When multiple homogenous containers are managed and orchestrated together, they form a microservices application. Microsoft claims that Service Fabric is the foundational technology for Azure core infrastructure. It currently powers services including Skype for Business, InTune, Azure Event Hubs, Azure Data Factory, Azure DocumentDB. It is used to manage over 1.4 million customer databases in Azure SQL Database and Bing Cortana – which can scale to process more than 500 million evaluations per second. Developers can package their code as containers that will be orchestrated by Service Fabric. This technology is available on Windows and Azure today but will be ported to Linux and other cloud platforms as well.

9) Kubernetes and Mesosphere can be used on Azure to manage containers

Service Fabric may be in its early days, but that doesn't stop Microsoft customers to use proven orchestration tools like Kubernetes and Mesosphere on Azure. Since Windows Containers, Hyper-V Containers expose the same Docker API, these tools can instantly work with Microsoft containers. It is possible to mix and match Linux containers and Windows containers to build a composite, microservices application. Docker Swarm, Kubernetes, Mesosphere, and CoreOS Fleet may not distinguish the containers. This is a huge win for both Microsoft and Docker customers.

10) Azure Doesn’t Offer Container as a Service (Not Yet)

One area in which Microsoft is lagging behind Amazon and Google is hosted container service or Container as a Service (CaaS). Amazon has announced EC2 Container Service (ECS) at last re:Invent and recently made the service generally available. Google combined its expertise of Kubernetes with Google Compute Engine to offer Google Container Engine (GKE). There are other platforms such as Tutum and Joyent that are delivering CaaS. Microsoft may be waiting for its container technology to stabilize before exposing it to customers. When it is ready, Azure will be the first cloud platform to host and manage Linux and Windows containers.