Strategies for Moving .NET Workloads to OpenShift Container Platform

Introduction

Enterprises have saved costs, unlocked developer productivity, embraced CI/CD, and built scalable apps on modern environments using Linux containers and open source technologies. There are recommended processes and tools in the Cloud Native Trail Map that provide references for enterprises starting their cloud native journey. But firms have often struggled with  similar solutions for Windows platforms. So why is this a critical pain point? Windows Server still enjoys a significant presence among server operating systems in the datacenter. .NET has been and continues to be used widely for application development, with ASP.NET and ASP.NET core used widely as web frameworks. There are still plenty of legacy .NET applications running on Windows Server 2019, Windows Server 2016, and others in private clouds. In this blog, we will examine different strategies for running .NET workloads on Openshift, discuss trade-offs, and guide you to the tooling available to get started with your Windows modernization journey.

In December 2020, we announced the general availability of running Windows Container workloads on the OpenShift Container platform using the Windows Machine Config Operator (WMCO). There are several benefits of containerizing traditional Windows apps on OpenShift, including realizing the benefits of containers, modernizing and gaining efficiencies, and increasing developer productivity. Using WMCO, you can provision Windows worker nodes in your OpenShift cluster as a Day 2 operation.

OpenShift Virtualization

In August 2020, we announced the general availability of OpenShift Virtualization version 2.4 (formerly container-native virtualization):

OpenShift Virtualization (formerly container-native virtualization) lets developers bring virtual machines (VMs) into containerized workflows by integrating and consuming a virtual machine within OpenShift where they can develop, manage, and deploy virtual machines side-by-side with containers and serverless all in one platform.

OpenShift Virtualization is an operator that enables developers to create and add virtualized applications to their projects from OperatorHub in the same way they would for a containerized application. The resulting virtual machines will run in parallel on the same Red Hat OpenShift nodes as traditional application containers.

Windows Containers or Virtualization?

OpenShift Virtualization is a good strategy for rehosting existing virtual machines within Red Hat OpenShift with the goal of modernizing applications over time without having to rebuild. Windows Server Containers is a good strategy for refactoring .NET applications into containers and deploying to Windows nodes on Red Hat OpenShift.

Here are some qualifying questions you should consider when evaluating Windows Containers and OpenShift Virtualization:

• Does the application support Windows Server 2019?
• Windows Containers in OpenShift requires Windows Server 2019. OpenShift Virtualization supports Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, and Windows 10. VMs running Microsoft Windows Server are certified on OpenShift via Microsoft's Server Virtualization Validation Program (SVVP).
• Is the customer running OpenShift 4.6 or above?
• OCP 4.6 or later is required for Windows Container support. OpenShift Virtualization is available for use in deployments of OpenShift Container Platform 4.5 and later.
• Does the application have any desktop graphical elements?
• Windows containers are not meant for graphical applications, only console applications.
• Is the application already containerized in a Windows format?
• OpenShift does not provide specific extra tooling to help customers containerize Windows applications specifically, much like Linux. The application should be adapted to work in a container. You can, however, consider using Windows Admin Center for building your container artfacts
• Is the application built for a multi-ode architecture?
• For example, if that application relies on the Windows Registry, this is going to cause problems when scaling to multiple nodes.

Use Cases for Windows Container Workloads on Red Hat OpenShift

There are multiple options for bringing your .Net workloads to OpenShift, and each has a different risk/reward ratio. The following table provides the pros and cons of each option for running .NET applications on OpenShift:

Decision Tree for Targeting .NET Container Workloads on OpenShift

Here is a decision tree for targeting .NET container workloads on OpenShift. Windows Server 2019 is the only Windows operating system supported, enabling Kubernetes Node on Windows (including kubelet, container runtime, and kube-proxy). For a detailed explanation of Windows distribution channels, see the Microsoft documentation. This link summarizes .NET Framework version history and correlates each version with Visual Studio, Windows, and Windows Server.

As you can see, only .NET Framework 4.7.2 and above are supported on Windows Server 2019. So:

• If you are running a supported version of .NET framework (4.7.2 and above), you can containerize the apps and bring them to the Windows Server 2019 worker node on OpenShift.
• If you are running an old version of .NET framework (4.7.2 and below), you have to migrate the apps to .NET core, containerize them, and then you have the choice of running them either on Windows Server or RHEL/RHCOS worker nodes OpenShift. Note that .NET core is supported on RHEL/RHCOS. Microsoft establishes and maintains the life-cycle support policy for .NET on Red Hat Enterprise Linux.
• If you are already running .NET core app, you can skip the migration step from .NET framework, directly containerize them and deploy them on Windows or RHEL/RHCOS worker nodes.

Choosing Between .NET and .NET Framework Containers

There are two supported frameworks for building server-side containerized applications with .NET: .NET Framework and .NET 5. They share many .NET platform components, and you can share code across the two. However, there are fundamental differences between them, and which framework you use will depend on what you want to accomplish. This section provides guidance on when to choose each framework.

Use .NET 5, with Linux or Windows Containers, for your containerized server application, when:

• You have cross-platform needs. For example, you want to use both Linux and Windows Containers.

• Your application architecture is based on microservices.

• You need to start containers fast and want a small footprint per container to achieve better density or more containers per hardware unit in order to lower your costs.

In short, when you create new containerized .NET applications, you should consider .NET 5 as the default choice. It has many benefits and fits best with the containers philosophy and style of working.

Use .NET Framework for your containerized server application when:

• Your application currently uses .NET Framework and has strong dependencies on Windows.

You need to use Windows APIs that are not supported by .NET 5.

• You need to use third-party .NET libraries or NuGet packages that are not available for .NET 5.

Using .NET Framework on containers can improve your deployment experiences by minimizing deployment issues. This “lift-and-shift” scenario is important for containerizing legacy applications that were originally developed with the traditional .NET Framework, like ASP.NET WebForms, MVC web apps, or WCF (Windows Communication Foundation) services.

Decision Table: Which .NET Frameworks to Use

The following decision table summarizes whether to use .NET Framework or .NET 5. Remember that for Linux containers, you need RHEL/RHCOS hosts (virtual or physical) and that for Windows Containers, you need Windows Server based hosts (virtual or physical).

Porting to .NET Core

Want to make your libraries support multiplatform? Want to see how much work is required to make your .NET Framework application run on .NET Core? The .NET Portability Analyzer is a tool that analyzes assemblies and provides a detailed report on .NET APIs that are missing for the applications or libraries to be portable on your specified targeted .NET platforms. The Portability Analyzer is offered as a Visual Studio Extension, which analyzes one assembly per project, and as a ApiPort console app, which analyzes assemblies by specified files or directory.

To begin using the .NET Portability Analyzer in Visual Studio, you first need to download and install the extension from the Visual Studio Marketplace. It works on Visual Studio 2017 and later versions. Configure it in Visual Studio via Analyze > Portability Analyzer Settings and select your Target Platforms, which are the .NET platforms/versions that you want to evaluate the portability gaps. You should compare with the platform/version that your current assembly is built with.

More details here.

Conclusion

There is a spectrum of choices for bringing your .NET workloads to OpenShift, and each option has a different risk/reward ratio. OpenShift Virtualization is a good strategy for rehosting existing virtual machines within Red Hat OpenShift with the goal of modernizing applications over time without having to rebuild. Windows Server Containers is a good strategy for refactoring .NET applications into containers and deploying to Windows nodes on Red Hat OpenShift. Regardless of where you are in the application modernization journey, OpenShift provides a great platform for running your Windows workloads.

If you’re running Windows Server 2019, and OpenShift 4.6 and above, do take the Windows Machine Config Operator, available from the in-cluster OperatorHub, for a test drive and send us your feedback. You can also view a demo of the solution here. You can Get Started with OpenShift Virtualization by downloading and installing the operator today, and also watch a live demo, with our OpenShift experts.