When Microsoft announced in November 2014 that the .NET Framework would be open source, the .NET developer's world shifted. This was not a slight drift in a new direction; it was a tectonic movement with huge implications.
For one thing, it positioned .NET developers to take part in the rapidly-growing world of Linux containers. As container development matured to include technologies such as Kubernetes, Knative, and Red Hat OpenShift, .NET developers faced the opportunity—and challenge—of moving existing applications to use microservices and containers.
Fortunately, we have options. This article describes three paths for .NET development for OpenShift: Linux containers, Windows containers, and OpenShift container-native virtualization.
Linux is containers, containers are Linux
.NET Core is the most obvious and direct route to .NET in containers. Containerizing a .NET Core application is as simple as writing a Dockerfile and building the image using Podman or Docker. While it does require either a Linux-based computer or the proper Windows-based environment (Hyper-V or Windows Subsystem for Linux 2), no special steps or OpenShift technologies are needed. Build the image and import it to OpenShift.
Using Linux containers would seem to be the preferred route for new ("greenfield") applications because no porting or rewriting is needed. If you want to port an existing application, two tools can help: Microsoft's ApiPort and Amazon's Porting Assistant for .NET.
If you want to start writing .NET applications to run in containers while keeping your existing monolith running in Windows, I suggest learning about the strangler pattern.
If you want to start a new application, or if you can easily port your current application, or if you want to employ the strangler pattern, .NET Core running Linux containers is the way to go.
But what if you want to move an existing .NET Framework application immediately?
Windows containers
The long-awaited Windows containers technology is here and ready for you to run with it on OpenShift. Using the same management model—and the same management plane—as Linux containers, Windows containers allow you to build and run images on the Windows operating system.
What is the practical takeaway of this? How about the ability to run .NET Framework applications in containers? Yes, Framework. Not Core; Framework. Let your imagination run wild with that for a moment. Build a Windows container image, and running your IIS website can be as easy as docker run -d -p 80:80 my-iis-website.
There are, of course, a few things to consider when using this approach. I will explore these points in an upcoming article about Windows containers on OpenShift. Stay tuned.
OpenShift CNV
OpenShift container-native virtualization, or CNV, is built on the KubeVirt technology. The KubeVirt project lets you control a virtual machine (VM) with Kubernetes, treating it like a container. The many advantages of this technology, coupled with OpenShift, include immediate lift-and-shift without any code changes, role-based access control (RBAC) and networking policies as afforded by OpenShift, and more. In short, you get all the advantages of Kubernetes and OpenShift while keeping your Windows VM running.
If you want to move your legacy .NET Framework applications to OpenShift and benefit from its features immediately, this route could be the best. It buys you time as you evaluate your path forward, which might include containers—Windows, Linux, or both.
More to come
This article was only a brief introduction to the latest technologies for containerizing .NET applications. Your individual path depends on your situation, budget, time, and so on. To help make the decision easier, look for three more articles on this topic—one for each path: Linux containers, Windows containers, and OpenShift CNV with a Windows VM.
Last updated: April 15, 2021