#CloudDesign: Design changes for migrating from on-prem app to a Cloud Native world

This article will demonstrate how organisations can transition their on-prem hosted web apps to a cloud native workloads and take advantages of enormous elasticity, scalability and availability features. This article will also highlight challenges, introduction of complexity due to migrating to the cloud and how Devops tools can be used to solve complexiting within additional components, services, configuration and process can be streamlined to leverage maximum values from the cloud.

For the purpose of this article we will assume that we have an ASP.Net application to be moved.

Typical business application has a frontend and a backend aspects where frontend acts as layer providing services such as view layer, business, data access layer along with maintaining secrets and provide caching services. Making them

First Thing First — How the As-Is and To-Be Design may look like

As-Is

In an On-Prem architecture, common ASP.Net application will be hosted on a webserver(not consider enterprise wide setups consisting of 100’s of web servers, our case may only consider 1 or 2 webservers sitting behind a load balancer with a sticky session switched on) and they usually interface a database for persisting data. Applications usually manage secrets within a configuration file(web.config), provide cache, session and other services. In an ideal scenario following activities will happen(shown with a sequence diagram):

1. User invokes the web app by entering url in the browser window.
2. Request is received by the ASP.Net Frontend.
3. App will check database access key in the web.config file.
4. App will then invoke a call to the database.
5. Database will provide results against the triggered query.
6. App will recieve response from the database
7. It will cache frequently used data in the application cache, most probably on the same webserver.
8. Data is binded with the control and view is returned back to the user.

Depiction of compontnent you may need in standard ASP.Net App

To-Be

Identified application for migration to the cloud platforms like Azure, may need to be broken down slightly and will need introduction of few more Azure based cloud native services apart from usual services which will be used for ASP.Net application and database hosting. These services are usually consumed to align cloud native application style, as the legacy application style may not address some of the cloud specific concerns like secrets management, cache data management, stateless application style. Please note that the functional behaviour of the application will still remain the same, ways to manage application code, unit test on developer workstation will still remain the same.

You will have multiple options at your disposal to achieve the above design in the cloud with different types of pros and cons and they may need little to considerable code changes. These options are:

1. IAAS based option — use a VM to host your code. This will be a lift and shift approach but is a viable option specially in cases where you want almost no code changes, will be the cheapest in terms of developer utilisation, with negligible test effort involved. It will definately add a todos in your technical dept.
2. PAAS based option — this option will utilise a Azure App Service for App hosting. This is again a viable option which reduces future challenges in case scalability is required during peak season traffic management. This approach way more flexible, scalable and available compared to IAAS based approach and bring your tech stack much closer to cloud native taxonomy
3. Serverless option — this is the most futuristic option but will need considerable efforts to refactor your frontend application to smaller pieces. UX may need to be broken down to Micro UI/s either based on ASP.Net Core MVC(hosted in a container inside AKS) or React based client MVC apps(hosted in Azure Storage). Business layer may need to be broken down to domain specific Microservices API. You may even chooses simpler, lightweight platforms like Node.Js(hostable in Azure Functions Apps or within a container in the AKS).

For further discussion in this article we will consider utilising Azure PAAS based option — Azure App Service.

Migrated application will leverage following cloud services in its new avataar:

1. Azure App Services, for stateless PAAS hosting.
2. Azure KeyVault, Providing secure secrets management.
3. Azure SQL, for cloud data persistance.
4. Azure Redia Cache, manages application cache data.
5. Azure Monitor, Log Analystics and Application Insights(not shown in diagram below)

ASP.Net Web App in Azure Public Cloud

Flow of the application control flow with use of above services will be something like this(also highlighted with sequence diagram above):

1. User invokes the web app by entering url in the browser window.
2. Request is received by the ASP.Net AppService Frontend.
3. App will check Azure SQL secrets from Azure KeyVault Service(this is the safest place on a public cloud). Please note that application secrets will be off the application web.config file where they were usually maintained in clear text. This is done to derisk exposure of secrets as they will be managed by most secure cloud storage.
4. App will invoke a call to the database by using secrets from Azure Key Vault.
5. Database will provide results against the triggered query.
6. App will recieve response from the database
7. Application will move frequently used data to the Azure Redis cache service.
8. Data is binded with the control and view is returned back to the user.

Complexity

It is clear that the the change in architecture from on-prem to the cloud platform will lead to introduction of new services and will lead to introduction of additional complexity(or you can say that it will bring additional baggage) in the enterprise landscape. The problem will spiral as you decide to add more and more application.

How challenges can be solved

Solution to this problem is use of good Devops tooling — one such example is Azure Devops. It can be used to:

1. Handle version control.
2. Manage Application infrastruture and configuration management.
3. Automate release management by using CI/CD.
4. Dependency Management and
5. Test Automation

Conclusion

As seen in above discussion it is easy to move on-prem workloads to public cloud platforms by slight changes to the application patterns and by utilising additional cloud native services. Additional complexity can be managed by usage of devops tooling.