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:
Step |
Red Hat OpenShift feature |
Use case |
Advantages |
Trade offs |
Rehost |
OpenShift Virtualization |
Lift and shift Windows virtual machines to OpenShift |
Easy and low friction |
Few benefits of containerization |
Refactor |
Red Hat OpenShift support |
Containerize and run traditional .NET framework apps on Windows Server containers and deploy to Windows worker nodes on Red Hat OpenShift Container Platform |
Benefits of containerization and OpenShift |
Evolving Windows container ecosystem, supported only for newer version of Windows including Windows Server 2019 |
Rearchitect |
Red Hat Enterprise Linux Red Hat Enterprise Linux CoreOS |
Migrate traditional .NET frameworks apps to .NET Core and deploy to Red Hat Enterprise Linux containers in OpenShift. |
Full benefit of containerization and OpenShift, highly evolved community |
Migration effort involved, time consuming |
Rebuild |
Red Hat Enterprise Linux Red Hat Enterprise Linux CoreOS |
Build cloud native apps using Linux containers and deploy to Red Hat Enterprise Linux/Red Hat Enterprise Linux CoreOS containers on OpenShift. |
Full benefit of containerization and OpenShift highly evolved community |
Net new development may not be an option for customers running in maintenance mode |
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).
Architecture / App Type |
RHEL/RHCOS containers |
Windows Server Containers |
Microservices on containers |
.NET 5 |
.NET 5 |
Monolithic app |
.NET 5 |
.NET Framework .NET 5 |
Best-in-class performance and scalability |
.NET 5 |
.NET 5 |
Windows Server legacy app (“brown-field”) migration to containers |
- |
.NET Framework |
New container-based development (“green-field”) |
.NET 5 |
.NET 5 |
ASP.NET Core |
.NET 5 |
.NET 5 (recommended) .NET Framework |
ASP.NET 4 (MVC 5, Web API 2, and Web Forms) |
- |
.NET Framework |
SignalR services |
.NET Core 2.1 or higher version |
.NET Framework .NET Core 2.1 or higher version |
WCF, WF, and other legacy frameworks |
WCF in .NET Core (client library only) |
.NET Framework WCF in .NET 5 (client library only) |
Consumption of Azure services |
.NET 5 (eventually most Azure services will provide client SDKs for .NET 5) |
.NET Framework .NET 5 (eventually most Azure services will provide client SDKs for .NET 5) |
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.
À propos de l'auteur
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit