The Windows and Linux Container Era is Here
There will probably always be good reasons why no developer in his or her right mind would ever want to intentionally build a distributed application that runs partly on Windows Server and partly on Linux. But in this modern era, applications are rarely conceived, produced, and deployed as whole entities anyway. The “Stack” part of “The New Stack” concerns the services and platforms that developers need to build new applications that scale up beyond any kind of scale we’ve known before.
Segregation doesn’t make sense in this new world. And that’s exactly what the division between “Linux apps” and “Windows apps” truly is, at this scale: segregation.
Wednesday morning, Microsoft took the next step in breaking down the wall that (let’s be honest) it helped build, and for many years reinforced. As first promised last April, the company released its preview of Windows containers — essentially Docker containers packaging Windows content — along with the Docker-branded tooling necessary to run those containers in a Windows environment, with the company’s third preview build of Windows Server 2016.
“If an operations team has already tooled up, and built its deployment and monitoring and management tooling around the Docker APIs for Linux applications, the very same tooling will work as-is for Windows applications,” explained Scott Johnston, Docker’s senior vice president for product marketing, in an interview with The New Stack. “There’s this wonderful ‘one-plus-one-equals-three’ where you get a uniformity of operations tooling across each of our technology stacks, while still giving the application owners the power of choice, where they can choose the right stack for the right job. They can choose the Windows stack for a Windows service, if it’s tooled for that use case, and a Linux stack for another use case.”
Making Windows Workloads Run on Linux
It’s not exactly a situation where you can drop a Windows container onto a Linux server, physical or virtual, and suddenly find yourself running Exchange or SQL Server on RHEL. Although a container often includes a small operating system (with Windows containers, there’s Nano Server, which also makes its public premiere Wednesday), it’s the kernel of the OS host which provides fundamental resources to services in the containers it hosts.
But in April at the company’s Build conference, and again in May at Ignite, Microsoft clearly demonstrated Linux workloads running in Docker containers on Windows. It’s done through the aid of a Linux VM running on a hypervisor (Microsoft naturally suggests its own Hyper-V, but ESX or KVM should work as well). Using Docker’s command-line tools, container images are retrieved from a registry and pushed to the VM. (You have to be careful when talking about Linux tools in Windows, because here, “Registry” means something else entirely.)
As Microsoft’s general manager for cloud marketing, Mike Schutz, confirmed to The New Stack, the converse situation will work:
A Windows VM running on a Linux-based host can run Windows workloads.
“We’re making it really easy in Azure, as an example, for a developer to be able to build these composite, microservices-based applications,” said Schutz. “Today in Azure, we have a pre-configured Ubuntu image with Docker tooling pre-installed. Similarly, we will have a Windows Server container host image, with the Docker tooling pre-installed, and the container capabilities enabled. So in just a couple of clicks, a developer can get going, and have a microservices-based container application running on Windows Server. They can also do it on a Linux VM; it’s going to run in this shared Azure infrastructure.”
Unsurprisingly, Microsoft gives a bit of deference to its own Azure cloud platform. Expect Visual Studio to be pre-configured for publishing containerized Windows applications to Azure; and also expect System Center, Microsoft’s principal Windows Server management tooling, to utilize Azure first for deployment of Windows-based container repositories (a whole, new phrase for Windows folks).
However, as Schutz also assured us, Windows containers will not be wedded to Azure. They will be just as portable as Docker containers have always been, because they use exactly the same format — what we now call the OCI format. Microsoft is a charter member of the Open Container Initiative.
The availability of these first Windows containers will not lead to a sudden wellspring of long-standing Windows applications, such as Word and Excel, becoming containerized and wading into the foreign waters of Linux. In fact, these first containers will essentially be home for applications built with Visual Studio and compatible with Windows, but designed for containers. In other words, while these new applications could run in Windows outside of containers, they are not quite the same architecture as typical Windows apps … which may not run in this style of container.
There’s an unavoidable technical reason for this: Windows applications need the Registry (capital “R”) and other essential Windows resources that cannot be easily miniaturized. If they could, hard disk drives in laptops everywhere would have a lot more space.
The Other Windows Container
But there will be containers for these more conventional Windows apps — just not the kind premiering Wednesday. Microsoft’s so-called “Hyper-V containers” will use essentially the same image format (whether it ends up being truly OCI remains to be seen), though it will include more of those resources that a typical Windows application requires to feel at home … or, more accurately, to pretend that it is at home inside a comfy Intel or AMD processor.
As Schutz confirmed, this second class of container will make its premiere in a later preview edition of Windows Server 2016 (WS2016). What remains to be seen is the extent to which Hyper-V containers will successfully carry Windows Server-based applications into a Linux environment.
Last May at Ignite 2015 in Chicago, Microsoft Senior Program Manager Arno Mihm promised developers that both styles of containers will, eventually, be capable of running “anywhere.”
“With Hyper-V containers, what we did is, we took the Windows Server container and put it in a Hyper-V partition wrapper,” explained Mihm. “And by doing so, we have all the benefit that we have gained with Windows Server containers, with respect to deployment, the layering, and the tools that we use; and at the same time, we added an additional layer of isolation that is even backed by hardware properties as well.”
That additional layer of isolation may actually have been unavoidable:
Traditional Windows applications are, by design, isolated entities. They will not become microservices, and we should not expect Hyper-V containers to become vehicles for microservices-based applications.
As the brand name implies, this class of container will require Microsoft’s Hyper-V hypervisor. But Hyper-V containers will bring traditional Windows applications into the hyperscale data center, and it’s quite possible that they may be incorporated into composite applications in the near future.
As Taylor Brown, also a Microsoft senior program manager, told developers during the same Ignite session, the only difference that DevOps professionals should notice when deploying containers using the two formats, using WS2016’s built-in Docker tools, will be a single flag on the docker run command.
From left to right: Taylor Brown, Arno Mihm — senior program managers, Microsoft
“All of the container management tools that we’re working with, and all the ones we foresee others working with, will be able to do Windows Server containers or Hyper-V containers in exactly the same way,” said Brown.
“We think it’s really important that we give the flexibility to IT pros, like yourselves, to identify the right workloads to run inside of a Hyper-V container, because you’ve got a compliance need, because you need that level of isolation, while not having to worry whether this tool or this environment is going to support it or not.”
However, as Brown went on, any brand of hypervisor capable of hosting a Windows Server-based guest can effectively run Hyper-V containers, albeit one step removed. The Hyper-V hypervisor is itself hosted by the Windows guest.
“This is really important. It means that we can run the Hyper-V containers anywhere.” said Brown. “We can run Windows Server containers anywhere. There’s no real limitation on where those container types can run.”
But that future preview build of WS2016 (we don’t know yet whether it’s the very next one) could give us our first clue as to whether there will be limitations on what kinds of Windows application workloads this second class of Windows container can run.
