Supporting Windows Server Containers with Red Hat OpenShift

At Red Hat Summit 2017, Red Hat and Microsoft shared the stage to demonstrate many of the technologies and tools that have come out of our alliance. At the end of the session, there was one subtle, yet impactful, demonstration that may end up having a significant long-term impact as it evolves. As a quick recap, during the keynote demonstration, the joint team showed the following:

A .NET Core application built and deployed running next to the Java application and using the same SQL Server instance

A Skype Chat-bot using Azure Serverless Functions talking to the deployed .NET endpoint

OpenShift Origin orchestrating and scheduling a Windows container running IIS on a Windows 2016 Server -- even proving it by displaying a Windows command prompt from within the OpenShift console

That’s a pretty significant list and a very packed 10 minutes, but let’s focus on that last bullet because based on today’s announcement, Red Hat and Microsoft are embarking on a joint effort to deliver Windows Server container support commercially within Red Hat OpenShift, moving us from project to fully supported product. With this work, users will be able to orchestrate and schedule Windows containers within Red Hat OpenShift using the same tooling and management used with Linux containers.

You read that correctly: common orchestration and scheduling for Windows Server containers and Linux containers on the same platform.

After this demonstration, we received strong interest from many Red Hat customers who wanted to have this capability fully developed and jointly supported by both Microsoft and Red Hat. To be clear, there is a lot left to do with months of work ahead as we pursue this path, but in the topsy turvy world of containers and container orchestration, this should be a significant step in what could prove to be one of the most valuable integrations to come out of Red Hat’s alliance with Microsoft. Trying to get Windows to work natively with OpenShift is nothing new -- in fact, in our legacy architecture, we worked with a technology partner to do something similar from a community perspective. This was then followed up with work around .NET Core, which is now a commercial and supported runtime with Red Hat OpenShift and Red Hat Enterprise Linux.

However, even with these initiatives, the ideal world for customers is a singular container orchestration fabric that supports the two leading commercial operating systems in customer datacenters -- Microsoft Windows and Red Hat Enterprise Linux. Concentrating on the orchestration paradigm, while still complicated, is not nearly as complex of an engineering challenge as the prospects of attempting to create a universal container runtime that works on all operating systems with equal efficiency. Moreover, it is presumed that each operating system will be optimized for their respective container runtimes due to vastly different system designs. Working on orchestration integration can enable the commercial operating system best practices to remain in place and, ultimately, create a better experience for the end user operating at the container application level.

Said succinctly, let Windows run Windows Server containers and Red Hat Enterprise Linux run Red Hat Enterprise Linux containers, while OpenShift orchestrates them as building blocks to compose your next generation applications.

Another implication of this is legacy .NET support. Though .NET Core 1.X and 2.X can run in a Red Hat Enterprise Linux container today with OpenShift, adding this new Windows container capability would open up the platform to older .NET 3.5 and 4.X workloads (of which there are thousands upon thousands), making OpenShift a bridge to help customers into the new paradigm of containers and container orchestration, no matter their preferred runtime or framework. The capabilities of OpenShift would be available not only for your Linux containers, but also your Windows containers -- customers could continue selecting the right tool for the job without significantly changing how they work.

This effort started with open source community efforts and it is a combination of this alliance and community involvement that will move this forward. The Kubernetes Windows SIG was created to help deliver this ubiquitous orchestration goal. In fact, the demo shown during Red Hat Summit in Boston (and above) was based on work that came out of this SIG that enables interoperability of Windows with Kubernetes. It will be interesting to see how this evolves in the coming months with both Microsoft and Red Hat engagement, but the goal of the truly unified container application platform may not be as far fetched as it once seemed.

I look forward to being part of this technology as it evolves through the combination of open source community work and joint Red Hat and Microsoft engineering effort. Achievement of this goal would, of course, be followed with subsequent releases and support via integrated support between the companies. The bottom line is that we are now enabling the true promise of the hybrid and container architectures for our customers, and what an exciting time it is.