Top 10 things while migrating existing Web Applications to Azure
Microsoft Azure is another sophisticated hosting platform. For Web Sites where we have code written and wanted to move it to Azure we would obviously be facing some challenges if it as never designed for distributed environment,
1. Should not use In-Proc Sessions. In Web development it is very common to use sessions. Sessions are for local web servers and this is not accessible outside of the server. So in distributed environment we can have same copy in different server with a load balancer sitting on top of it, user can land in any node depending on the availability etc. So if someone comes to Machine 1 and login to the portal and in next click he may land to another machine. So the session which could contain user name to be displayed in each page is now null.
Candidate solution: Use distributed caching. Azure offers Redis Cache which is a managed caching service. Use Redis cache for more enterprise approach. Managed Cache and In Role cache are mainly for legacy approach. Redis is recommended. Here is, how to use Redis Cache for ASP.NET Session https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-session-state-caching/
2. Avoid Windows Authentication in SQL Server. Windows Authentication and SQL Server is very common in Line of Business Applications. This allows easy access and setup. Sometimes we leverage AD security groups to allow access its backend SQL Databases. That solves additional coding effort while defining various level of security and access to db. However this may not work as is if you move your application to Azure in Platform as a service mode.
Candidate solution: Use SQL Authentication wherever possible. If you move your database to Azure SQL Database then you have only SQL Authentication available. Also you need to understand the limitations of Azure SQL Database and SQL Server (on-premises). Please refer the official documentation https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/. Another alternative solution could be to use WCF service with Azure Service Bus to connect the on-premises database. For some pointer please refer my blog on how to connect on-premises SQL server using Azure Service Bus https://blogs.msdn.com/b/wriju/archive/2015/07/09/connecting-on-premises-sql-server-using-azure-service-bus-relay.aspx
3. Replace Windows Service. Often Web Application uses Windows Service to perform backend activities like cleaning up system or database job. In Azure we have Windows Service when we have application hosted in a VM (Infrastructure as a Service). But in most cases this is not an elegant solution.
Candidate solution: The best approach is to take CQRS pattern with Worker Role. For CQRS pattern please refer https://msdn.microsoft.com/en-us/library/azure/dn568103.aspx. Another option is to use Web Jobs with Web Apps. But avoid Web Job for large processing as this stays in the same machine where your Web App is. This might create bottlenecks for your web portal for long memory consuming activity. For everything on Web Jobs please refer https://azure.microsoft.com/en-us/documentation/articles/websites-webjobs-resources/. If the processing is very large and need a lot of computing resource please use Azure Batch, refer https://azure.microsoft.com/en-us/documentation/services/batch/
4. File Upload to local. In many Web Applications we have file upload feature. It could be an image or some document. Immediate solution is to upload them and keep it in local web server folder. However this is not a good design in distributed scenario as discussed earlier.
Candidate solution: Use Azure Blob Storage. This just as amazing as you expect. For .NET API of Azure Blob and how to use please refer https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-blobs/
5. 3rd party component. Any 3rd party component which requires installation and has to be there in Global Assembly Cache (GAC) to be avoided. Otherwise we could go for Virtual Machine in IaaS mode.
Candidate solution: The only option of deploying it to Infrastructure as a Service. Otherwise you can also use Cloud Service and startup task to deploy them. However, all the installer should have silent installation option.
6. Select right platform for right kind of application. If you need to move Web App as Lift and Shift mode, go for IaaS. Else you must and only consider Web Apps. Cloud Service could be another option but as of today I don't see a reason why one would not select Web App over Cloud Services.
Candidate solution: There is not on-size-fits-all. So select wisely as per business need.
7. Authentication and Authorization. When we move on-premises Web Application to cloud the first thing we would miss is the integrated Windows Authentication. So need to plan accordingly.
Candidate solution: Leverage Azure Active Directory as immediate solution with Directory Sync. But this would require code change as we need to use OAuth, SAML etc. This is a biggest road blocker in migration. Here is how you can authenticate ASP.NET Web Application with Azure Active Directory https://azure.microsoft.com/en-us/documentation/articles/web-sites-authentication-authorization/
8. Don't create the deployment slot for Web Load Test. Once you create a deployment slot it creates the web app in the same virtual machine. So by running Load Test would consume the shared CPU and RAM which is definitely a performance issue if we are running a live site.
Candidate solution: Have a separate Web App created for testing.
9. Implement SSL. Implement SSL using a valid certificate from a recognize certificate authority. When things are in on-premises we don't really need to think about SSL. However, moving it to public cloud need more caution as it is prone to hack.
Candidate solution: Valid certificate form CA and CNAME mapping with domain centric binding would make sure of your authenticity. Steps how to implement SSL https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure-ssl-certificate/
10. Scale-out not Scale-up. By increasing the VM capacity does not guarantee the best performance, select the distributed approach.
Candidate solution: Use Auto Scaling if possible this reduces the headache of waiting for the things to break. Test-test and Test until you are satisfied.
Happy migrating….
[Updated on July 10, 2015 with reference links]
Namoskar!!!
Comments
Anonymous
November 09, 2015
Namaste!!! dude, This is pretty goodAnonymous
August 14, 2017
Excellent Article!