Moving an existing web site to Microsoft’s Azure Web Apps has never been easier. But if you want to leverage the cloud scalability of Azure, there are a few things to consider before you make the move.
- Don’t Use In-Proc Session Management
Azure web apps are designed to be scaled out, meaning you will often have multiple instances running. When running behind a load balancer, each request can be directed to any of the available instances which might not be the same one that holds the session state from the last request. If your web app currently uses in-process session management you’ll want to change that to save the session data external to the web app. There are several options available but the perhaps the most scalable option is to use Redis Cache. This article has a great example of how to use Redis Cache for holding session data in your web app. - Use SQL Server Authentication
It’s a common practice for enterprise applications to use Windows Authentication between your web site and SQL Server. This is a simple process thanks to both servers running in the context of a network domain (or trusted domains). In Azure, your web app runs in a context that is not under your control and can change at any moment. For that reason you’re best bet is to use SQL Server authentication between your web app in Azure and SQL Server. - Don’t use Local file storage
Many web sites allow users to upload files or content directly the local file system of the server. But once again Azure’s distributed nature makes this a problem as the next request may expect to find that file and it won’t exist. Instead, you should upload the file to Azure Blog storage which can be accessed by all of the running Azure Web App instances. Here’s an article on how to set this up for your web app. - Avoid External Dependencies
It’s a fairly common practice for enterprise web sites to be built using components or features that are installed on the web server, either in the GAC or perhaps registered as COM components. You won’t be able to use these in Azure Web Apps. If your app requires one of these components you should probably look at either Cloud Services or a Virtual Machine hosted in Azure. - Don’t use deployment slots for load testing
Azure Web Apps provides you with multiple deployment slots to host staging or other instances of your web app. While functional and user acceptance testing using deployment slots makes a lot of sense its important to remember that all of your deployment slots are hosted on the same virtual machine. If you run your load tests on one of those slots you could cause issues with your production instance. Instead, you should create a separate web app with the same tier as your production instance.
Microsoft has a tool to help you move your entire web site including SQL Server backend to Azure. Read more about the Web Apps Migration Assistant in this article and run it here.