Got Legacy Applications? Not sure how to migrate ’em to cloud? Welcome to Azure PaaS with ASEv2
How to move your existing (legacy) .NET applications to Azure using PaaS approach with ASEv2
Moving has never been easier, could it be real life moving or legacy .NET applications. Thankfully, there is good news from Microsoft Azure. Many companies are still running apps on Windows Server 2003 and 2008 in the data center. They want to move to a modern, secure, supported platform in any cloud tomorrow. With few things to keep in mind, anyone can migrate their legacy .NET Applications to Azure.
“Time is a circus, always packing up and moving away.”
— Ben Hecht
What involves in Moving a legacy .NET Application
On top of this .NET applications, you might’ve your company proprietary software for security and data access. This article is to keep ASEv2 in focus but will also describe what factors lead to use ASEv2 and in which scenario one can use ASEv2 for moving their apps.
Identifying (candidate) Applications
There are various types of .NET Apps: intranet, internet, smart client applications, WCF, API. When it comes to Azure migration, we are talking about Web Applications which generally are hosted on IIS. Ideal candidates would be ASP.Net Web applications (Web Forms or MVC) and WCF.
Networking
Application networking plays a big role in deciding, can you go to Azure and what it takes to connect intranet apps and database from Azure. It is also important to decide migration approach, one by one app or cut-over. It is always a good strategy to migrate individual apps and not to lift and shift. If your investment is heavy on-prem and would still like to continue using Database and internal services, you would need VPN. To connect to the on-prem network, you would need Express route VPN or Point to Site VPN.
Identify Azure PaaS capabilities
Azure has multiple capabilities Iaas and Paas. You definitely do not want to maintain another infrastructure, so we are not even going to IaaS, in this article we will discuss the PaaS approach. The ASE is a single tenant instance of the Azure App Service that runs in a subnet in your VNet. This makes it desired by security teams across all industries for providing PaaS capabilities to their companies.
App Service environments (ASEs) are appropriate for application workloads that require:
- Very high scale.
- Isolation and secure network access.
- High memory utilization.
This article by Paco de la Cruz explains in depth on when to use ASE. Here is how to create ILB ASE.
App Service Plan
In App Service, an app runs in an App Service plan. An App Service plan defines a set of compute resources for a web app to run.
Security
Web application firewalls help secure your web applications by inspecting inbound web traffic to block SQL injections, Cross-Site Scripting, malware uploads & application DDoS and other attacks. Security is backed into Azure ASE when you Integrate ILB ASE with an Application Gateway.
Cloud Source Control
If you are moving to Azure cloud, you most probably would move or are already using Visual Studio Team Services (After all, it’s all about Ecosystem) Microsoft Azure has tight integration with VSTS. Since ASE runs on a subnet which is on your VNet, integrating with VSTS (CI/CD pipeline) will not be as smooth as deploying on multi-tenant Azure Websites. You would need a privately hosted build agent. This article explains how to integrate VSTS with privately hosted Azure App Service.
Setup CI/CD Pipeline
Create Build and Release pipeline. Again, you do not want to maintain various frameworks and Visual Studio IDEs on your private build Agent, keeping that aspect in mind, you would use hosted Agent for build pipeline and private agent for Release pipeline.
Create a strategy for deployment in Release Pipeline, you can have multiple environments (slots) in your Web App like Dev, Test, Staging, and Production. You can also setup Production Swap or Swap between multiple environments to enable the possibility of quick rollbacks of unwanted release reducing offline time.
Know the Azure limitations for your Apps
No Registry, Azure AD is different from on-prem windows AD.
Fill the Gap with Azure offerings
If your goal is re-write your app to migrate to Azure, then you can skip this step as this step is mostly for those who want to make the minimum changes to their app and move it to azure.
When you run out of all other options, (I would not use a term, someone just taught me) is when you would resort to writing your custom library to bridge the gap between Azure offerings and current implementation.
There is no registry in Azure. If you are using registry settings in your app, you ought to change that component.
Secrets
Every App will have some sort of secret. In cloud, Azure Key Vault is the way to store the secrets. This is not must have upgrade but nice to have feature to store any of your secrets (e.g. DB connection string, keys, secret) and from accidentally being accessed by developers.
Active Directory
The azure active directory is not same as an on-prem active directory. There are connectors out there to sync on-prem AD with the azure ad but you would need to rewrite your app or create a library to keep the same user experience using Azure active directory. This applies to mainly intranet apps which use windows AD (e.g. Windows Authenticated WCF, Windows Authenticated Web App).
Modify the App
Some Math here, find the least common denominator. When you use all the above factors and components, what is the least common denominator for the .net framework. Depending on the components used, the minimum could be .net framework 4.5.2. Upgrade the framework of your .Net Application if it is not already 4.5.2.
If you created a .net library (you definitely would need to bridge the gap), you probably would create a NuGet package. With the NuGet, you probably would be using private feed. VSTS offers a private feed for your packages.
Debugging & Tracing
I forgot to Mention the Debugging and Tracing capabilities of Kudu console can be helpful a lot for my journey to Azure. you can debug your app in Cloud using Visual Studio 2017. You can also Trace your code.
