Friday, May 1, 2015

Migrating On-premise .Net Web Applications to Microsoft Azure - Part 1

Microsoft first released Classic ASP, a server side scripting language by 1996 with IIS 3.0 as an add-on which opened many gates for developers to build a truly dynamic websites for businesses. Later Asp.Net 1.0, an advanced platform built on top .Net Common language runtime with full support for SOAP messages, XML, Object oriented programming, Web forms etc. From 2002 till 2009, Microsoft released enhancements and new versions of runtime, finally by 2010 officially released Asp.Net MVC, a cross platform development methodology to build application in Model-View-Controller Architecture which promoted distributed application development methodology. Asp.Net MVC helps developers to build scalable applications because it allows us to take full control of HTML rendered, TDD (Test Drive Development), Support for REST, and without state management components like Viewstates and SessionState mechanisms.

Although there are lot of advantages with the new ASP.Net MVC platform, there are plenty of Internal portals, public facing applications, commercial SaaS applications, built using various older versions of ASP.Net such as Asp.Net 1.1, 2.0,3..5, 4.0 web forms which heavily relies on View state and Session state component. This article doesn’t state applications built on older platforms are not scalable or slow, but the attributes mentioned above is not cloud friendly and anti-stateless which applies additional load on the webserver.

This article concentrates on the important considerations that developers have to bear in mind while they migrate onpremise hosted Asp.Net applications to Microsoft Azure.


 Enterprises and Businesses of various sizes approach us with a common set of similar business problems i.e.
  • 1. We have a public facing Web Applications built on ASP.Net 1.1 hosted on premise is having Scalability & Performance issues, Can you please help us.
  • 2. We have an internal Learning Management System built on ASP.Net 2.0 which we would like to host it on Windows Azure Web Hosting Plans 
  • 3. We have a hybrid app (Intranet + Public) built using Classic ASP has Security issues and we would like to Reengineer with the latest Asp.Net Platform.
  • 4. We have Apps built on Classic ASP which has issues with interoperability and Cross Platform integrations, how do we address it.
 These are very few scenarios, but there are plenty of other cases that we come across on a daily basis. Usually while consulting on migrations or up-gradation engagements, the first phase is to sit with business stack holders and understand the criticality of this apps and then dive deep into application study and dependency Identification etc. At 8KMiles, with our deep expertise in handling such projects, we have consolidated 18 key considerations that everyone should keep in mind while involved with application migrations to Microsoft Azure.

 Environment Considerations (PaaS/IaaS) 

 After decided with migrating self-hosted onpremise applications to Microsoft Azure, the next critical decision that you must make is the type of cloud service to host your applications. I.e. PaaS or IaaS. In a nutshell, PaaS provides the complete hardware stack, software stack including the runtime and lets the developer focus strictly on applications and not on the underlying infrastructure, IaaS on the other hand provides just the virtualized hardware alone and hence the responsibility of installing, patching the OS along with management of runtime component falls on the shoulder of developer, which is a painful process unless you have an internal/external IT team who can take care of this automatically or manually.

 From our experience in consulting many enterprise LOB applications, we found PaaS is suitable for their requirement with the benefits like automatic OS update management, integrated deployment management, scalability & elasticity, cost etc. However some customer have chosen Azure VMs which is truly the customer’s individual preference.

 It is very important to understand the basic differences between these combos. Microsoft Azure team has documented the common differences between these offerings and help you choose the best one for your app (Click here). Refer the comparison chart to decide PaaS or IaaS.

General recommendation is to carefully analyze the feature comparison between the three different offerings WebApps, Cloud Service (Web & Worker Role) and VM and wisely choose the one which best suit your requirement.

Database Considerations

Database is a key part of any data driven business solutions. Usually, SQL Server has been the default choice for legacy Classic ASP or ASP.Net applications and some might have worked with Oracle or MYSQL database. Whatever may be the database backend, Microsoft Azure has native database solutions while migrating to Azure Cloud.

As far as SQL Server is concerned, Developers have 2 major options to choose from 

1. Azure SQL (SQL server as a service)
2. Self-Hosted SQL Server on VM (IaaS)

Azure SQL is a fully functional SQL Server database as a service on cloud fully managed and serviced by Microsoft. Azure SQL offers loads of benefits and a natural fit for applications which was using SQL Server onpremise. Primary benefits of Azure SQL includes Elasticity on demand, no installation, automated patching, zero maintenance, high availability, Pay as you go Pricing model, unlimited storage(with elastic sharding) etc.

Along with benefits of Azure SQL, there are significant differences exists due to the inherent distributed nature of this service. They are discussed in details in the upcoming sections.

Self-Hosted SQL Server on VM, is another option where the customer can host SQL Server on their own with the overhead of all the benefits mentioned in the Azure SQL section above. With respect to the pricing, customers can opt for bundled license model or BYOL (Bring your own license) etc. Self-Hosted SQL on VM is ideal for situations like Lift and Shift model of deployment and quick migration path to Azure.

Below are some of the key considerations you have to bear in mind during the SQL Server migration to Azure.

Distributed Transactions

Distributed Transactions are not fully supported yet in Azure SQL. If your application heavily depends on Transactions, it’s not feasible unless you are ready to re-write the data access layer of your application and build custom transactions module to handle the data integrity on your own. If you don’t want to mess up with the application and you want a simple lift and shift and run model deployment, then SQL Server on VM is the best option to choose.

SQL Server Federation/Sharding

To overcome the limitation of single hardware failure and to achieve higher level of query performance, many applications use SQL Server Federation also known us Horizontal Sharding. Sharding was primarily used in scenarios where there is a heavy growth of data in a particular database or in a multi tenancy SaaS scenarios where each customer’s data must be stored in a separate database for better data isolation and data security.

Many existing applications had implemented custom sharding mechanism because of their unique business scenarios. If the applications that you are migrating have sharding implemented, you can achieve the same by using Azure SQL Elastic Scale. It’s technically the same as SQL Server Federation or Sharding, but it’s built for Azure SQL exclusive and doesn’t offer support for SQL Server on VM. 

There are 3 different Sharding techniques available. They are

  • 1. Federation on regular SQL Server 
  • 2. Azure SQL Federation introduced in Web & Business Tier (Deprecated from Sep 2015)
  • 3. Azure SQL Elastic Preview 
If your choice is Azure SQL, your existing Sharding infrastructure have to be entirely re-written using the Azure Elastic Scale API, because it provides a new implementation and SDK overarching the benefits of Elastic Scalability nature of Azure SQL. 

Similarly, if at all you use the sharding infrastructure of Web and Business Tier Azure SQL, Microsoft recommends you to adopt Azure SQL Elastic API. 

If re-writing or modifying your existing code base is not an option, obviously you have to bank on running SQL Server on VM.