Rehost an on-premises application to Containers

Rajeev Singh

3 years ago

To take advantage of the benefits of the cloud and new technologies like containers, you should at least partially modernize your existing .NET applications. Ultimately, modernizing your enterprise applications will lower your total cost of ownership.

Overview:

You can initially modernize your existing applications with important but easy to do modernization. You can maintain your current code base, written in existing .NET Framework versions, with any Windows and IIS dependencies. The below picture highlights how Cloud-Optimized apps are positioned in Azure application modernization maturity models.

Diagram of how to position cloud-optimized applications.

Business drivers

With a Cloud-Optimized application, you can rapidly and repeatedly deliver reliable applications to your customers. You gain essential agility and reliability by deferring much of the operational complexity of your app to the platform.

The Cloud-Native modernization maturity level usually requires new development investments. Moving to the Cloud-Native level typically is driven by the business need to modernize applications.

Migration goals

Your organization might not be ready to move to the cloud, or it might not be able to move to the cloud for business reasons. But you can still get the benefits of using Windows Containers in your own data centers.
You might have other artifacts that are being used on-premises, and which might slow you down when you try to move to the cloud. For example, security or authentication dependencies with on-premises Windows Server Active Directory, or any other on-premises asset.
If you start using Windows Containers today, you can make a phased migration to the cloud tomorrow from a much better position. Windows Containers is becoming a unit of deployment for any cloud, with no lock-in.

Solution design

With Azure, you have the flexibility to choose from a variety of hosting options for your applications spanning the spectrum of infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), containers-as-a-service (CaaS), and serverless.

Azure offerings such as Azure App Service and Azure Kubernetes Service (AKS) are helping application developers focus on solving the most important business problems.

Tools & technologies

The Azure Migrate App Containerization tool helps you containerize your applications and migrate them to Azure. In this preview, the tool can help you containerize ASP.NET applications running on Windows servers and Java web applications running on Apache Tomcat on Linux servers. The tool lets you package the application into a container image and helps you deploy the application container to Azure Kubernetes Service.

The Azure Migrate App Containerization tool currently supports:

Containerizing ASP.NET apps and deploying them on Windows containers on App Service.
Containerizing ASP.NET apps and deploying them on Windows containers on Azure Kubernetes Service (AKS).
Containerizing Java web apps on Apache Tomcat (on Linux servers) and deploying them on Linux containers on AKS.
Containerizing Java web apps on Apache Tomcat (on Linux servers) and deploying them on Linux containers on App Service.

The App Containerization tool helps you:

Discover your application components. The tool remotely connects to the application servers that run your ASP.NET application and discovers the application components. It creates a Dockerfile that you can use to create a container image for the application.
Build the container image. You can inspect and further customize the Dockerfile based on your application requirements and use it to build your application container image. The application container image is pushed to an Azure container registry that you specify.
Deploy to Azure App Service. The tool then generates the deployment files needed to deploy the containerized application to Azure App Service.

The Container Ecosystem in Azure

Before we start designing the proposed architecture, let’s understand the Container ecosystem in Azure.

Microsoft Azure provides an open and broad variety of choices, a full container ecosystem in the cloud (shown in the diagram below). Depending on your specific application’s needs, you should choose one or another Azure product.

These ecosystems are broadly categorized into IaaS and PaaS solutions.

	IAAS	PAAS
Overview	From the container ecosystem in Azure, the following products supporting containers that are considered infrastructure:	The products in Azure supporting containers that are at the same time positioned more in the PaaS (Platform as a Service) level are:
Products	· Azure Container Instances (ACI) · Azure Virtual Machines (With container’s support) · Azure Virtual Machine Scale Sets (With container’s support)	· Azure App Service · Azure Kubernetes Service (AKS and ACS) · Azure Batch

Containerization Use Case (when to use what)?

We explored to select the right Azure Compute in Re-Host scenario: App modernization- re-host scenario – Rajeev Singh | Coder, Blogger, YouTuber (wpcomstaging.com)

Now, let’s deep dive and check the use case for container options.

Containerization Decision Tree for Legacy Windows App

Before we decide to use it, let’s check the decision tree below, whether the application is supported for containerization or not.

Ideal candidates for containerizing

Type of application	Why these are good candidates	Special considerations
Console applications	With no GUI limitations, console apps are ideal candidates for containers.	Use the appropriate base container image depending on the application’s needs.
Windows services	Because these are background processes not requiring any direct user interaction	Use the appropriate base container image depending on the application’s needs. You need to create a foreground process to keep any containerized background process running. See the section on Background services below.
Windows Communication Foundation (WCF) services	Because they’re service-oriented apps that can also run in the background	Use the appropriate base container image depending on the application’s needs. You may need to create a foreground process to keep any containerized background process running. See the section on Background services below.
Web apps	Web applications are in essence background services listening on a specific port and are therefore great candidates for containerization, as they can leverage the scalability offered by containers	Use the appropriate base container image depending on the application’s needs.

What can’t be moved to Windows containers?

Applications/features not supported.	Why not supported	Can you work around this?
Applications requiring a desktop	Containers don’t support Graphic User Interface (GUI)	If the application only requires a GUI to install, changing it to a silent install might be a solution
Applications using Remote Desktop Protocol (RDP)	RDP is for interactive sessions, so the principle above applies here as well	You may be able to use Windows Admin Center (WAC) or Remote PowerShell as an alternative for remote management
Stateful applications	Containers are ephemeral	Yes, some applications might require minimal change, so they don’t store data or state inside the container
Database applications	Containers are ephemeral	Yes, some applications might require minimal change, so they don’t store data or state inside the container
Active Directory	The design and purpose of Active Directory precludes running in a container	No. However, apps that are Active Directory dependent can use Group Managed Service Accounts (gMSA).
Older Windows Server versions	Only Windows Server 2016 or later is supported	No. However, application compatibility might be an option – most Windows Server 2008/R2 and older apps run on newer versions of Windows Server
Apps using .NET Framework version 2.0 or older	Specific container images are required to support the .NET Framework, and only more recent versions are supported	Versions earlier than 2.0 aren’t supported at all, but see below for the container images required for later versions
Apps using other third-party frameworks	Microsoft doesn’t specifically certify or support the use of non-Microsoft frameworks on Windows Containers	Check with the vendor of the specific framework or app the support policy for Windows containers. See below for more information

When to use which Container Options (On-Prem VM, IaaS VM, ACI, ACS -Kubernetes)

Let’s summarize and deep dive on this topic:

The first step is to classify whether the App can be containerized or not.

The second step is to determine and use the options as mentioned below.

Use Case	Options
Need full-fledged Orchestration?	Azure Container Instance
Need full-fledged Orchestration and familiar with Service Fabric or older .Net Framework?	Azure Service Fabric
Using Red Hat OpenShift	Azure Red Hat OpenShift (ARO)
Need access to Kubernetes API?	Azure Kubernetes Service (AKS)
Don’t need access to Kubernetes API?	Azure Container Apps
Don’t need Managed service and own Orchestration implementation on Azure VMs	VMware Tanzu on Azure VM Kubernetes on Azure VM OpenShift on Azure VM

Let’s deep dive into these scenarios:

On-premises IaaS VM infrastructure

Use if don’t want to use Azure VM and get the benefits of using Windows containers in your DC.

Azure VMs (IaaS cloud)

If your organization is using Azure VMs

The main scenarios for using Windows Containers in an Azure VM are:

Dev/test environment: A VM in the cloud is perfect for development and testing in the cloud. You can rapidly create or stop the environment depending on your needs.
Small and medium scalability needs: In scenarios where you might need just a couple of VMs for your production environment, managing a few VMs might be affordable until you can move to more advanced PaaS environments, like orchestrators.
Production environment with existing deployment tools: You might be moving from an on-premises environment in which you have invested in tools to make complex deployments to VMs or bare-metal servers (like Puppet or similar tools).

Azure Container Instances (ACI)

The main value proposition of Azure Container Instances is that you can right away deploy containers to it and you don’t need to maintain that environment, you don’t need to upgrade/patch the underlying operating system or VMs, all that is transparent and you just deploy containers into a ready-to-use environment.

The reasons and scenarios when you would want to use ACI are similar to the main scenarios when you use Azure VMs with containers.

The main scenarios for using Azure Container Instances are:

Dev/Test scenarios
Task automation
CI/CD agents
Small/scale batch processing
Simple web apps

The main benefits of Azure Container Instances (ACI) are:

Run containers without managing servers.
Increase agility with containers on demand.
Deploy containers to the cloud with unprecedented simplicity and speed—with a single command.
Secure applications with hypervisor isolation

In short, with ACI you can develop apps fast without managing virtual machines or having to learn new tools. It’s just your application, in a container, running in the cloud.

Azure Container Service (Kubernetes)

Azure Container Service optimizes the configuration of popular open-source tools and technologies specifically for Azure. You get an open solution that offers portability both for your containers and for your application configuration. You select the size, the number of hosts, and the orchestrator tools. Azure Container Service handles the infrastructure for you.

If you are already working with open-source orchestrators like Kubernetes, Docker Swarm, or DC/OS, you don’t need to change your existing management practices to move container workloads to the cloud.

Use the application management tools that you’re already familiar with and connect via the standard API endpoints for the orchestrator of your choice.

For example, in Kubernetes, support for containers is native (first-class citizen), so using Windows Containers on Kubernetes is also effective (in preview in ACS as of early 2018).

Azure compute

As a by-default recommendation, the following is the main criteria recommended in this guidance:

Single monolithic app: Choose Azure App Service
N-Tier app: Choose orchestrators such as Azure Kubernetes Service (AKS) or App Service if you have a single or a few back-end services.
Microservices: Choose AKS or Azure Web Apps for Containers
Serverless functions & event handlers: Choose Azure Functions
Large-scale Batch: Choose Azure Batch

Current architecture

Now, it’s time to understand what’s the current architecture of the app.

The current App is a Web App and developed on .Net Framework 3.5
App Running on Windows Server 2012 R2.
IIS used 7.5
Don’t have any Windows Authentication.
The team doesn’t need a full-fledged Kubernetes platform that gives the team more control and flexibility over containerized applications.

Proposed architecture

Based on analyzing the current architecture, the team understands the requirements and comes up with the below-proposed solution.

Application qualities for containerization

Since App doesn’t need full-fledged control over the containerized app, the App can be containerized and migrated to Azure App Service.

Migration methods

The app can be containerized and migrated to Azure App Service using Azure Migrate App Containerization Tool.

The containerization process doesn’t require access to your codebase and provides an easy way to containerize existing applications.

The tool works by using the running state of the applications on a server to determine the application components.

It then helps you package them in a container image. You can then deploy the containerized application on Azure App Service.

Migration process

Below are the steps for this migration process:

Set up an Azure account.
Install the Azure Migrate App Containerization tool.
Discover your ASP.NET application.
Build the container image.
Deploy the containerized application on App Service

Prerequisites:

Identify a machine on which to install the tool.

Need a Windows machine on which to install and run the Azure Migrate App Containerization tool. The Windows machine could run a server (Windows Server 2016 or later) or client (Windows 10) operating system. (The tool can run on your desktop.)
The Windows machine running the tool should have network connectivity to the servers or virtual machines hosting the ASP.NET applications that you’ll containerize.
The Windows machine should have internet access, directly or via a proxy.

Application servers

Enable PowerShell remoting on the application servers.
Required PowerShell 5.1 on the application server.

Start Migration:

Set up an Azure account.

Install the Azure Migrate App Containerization tool.

Discover your ASP.NET application.
Build the container image.
Deploy the containerized application on App Service

Refer to this link for complete steps ASP.NET app containerization and migration to App Service – Azure Migrate | Microsoft Learn

Validate the deployment.

Once deployment is successful, validate the deployment and check app running is successful in App service.

Conclusion

In this article, we covered details of Containerization scenarios, when to use which container services. We explored asp.net application use case to understand the current architecture and proposed Containerization solution. Discussed about the steps for migration.

We covered scenarios to containerized applications to Azure App Service using Azure Migrate, in the next post we will talk about different aspects, such as Security, Monitoring, and day-2 operations guide (triage, ongoing maintenance of deployed assets, etc.)