Sep 30, 2013 Aathira Nair
During Windows azure migration, there are various concerns which crop up regarding storage, dependencies, session states etc.
Following are the major concerns which needs to be addressed, and a plan charted out prior to migration.
Windows azure migration would require complete application data migration, and this is a primary concern for many who are contemplating a move to Windows Azure. Depending on the need of the application, there are various options presented in the Windows Azure environment. If an application requires full SQL Server functionality, Azure Virtual Machines (VMs) are the ideal solution. Azure provides built in data services in the form of SQL Server relational storage and non-relational data storage services; using Tables, Blobs and Queues.
In a Windows Azure Web or Worker Role VM, the application has access to read and write to the local storage. However, given the stateless nature of VM instances in Azure, local storage is transient. Therefore the data that needs to be persisted must be stored outside the VM instance.
Data on the local drive is not synced with the drives of other VM instances of the application.
Therefore, new instances (added for capacity or restoration of failed VMs) will not have access to data persisted to local storage. Data on the local drive does not survive if an application deployed is subsequently deleted from Azure, and then later re-deployed. If the application does depend on the local drive for durable storage, you will need to plan for moving that data to either Windows Azure Storage or Windows Azure SQL Database.
SQL Database service offers a subset of SQL Server’s features and functionalities and hence some features of our application database may not be present in SQL Database. Analysis Services, Replication, Service Broker, DB Chaining and DB Mail are some of the features not currently provided as services on the Windows Azure platform. Hence,in planning a migration you will need to investigate where your application makes use of unsupported features.
As described in Local Storage above, if the application makes use of the local file system for durable data then moving that data to Windows Azure storage is our recommended practice. You should store static content such as script files, CSS style sheets, videos and images in blob storage. These static files can be served directly by the web server in the application’s VM. However, by moving them to blob storage, they are served to the users directly by the Windows Azure Storage service. Employing blog storage helps in reducing the load on the web server and also enabling us to later take advantage of Windows Azure’s Content Delivery Network (CDN).
Windows Azure environment does not include 3rd party frameworks/libraries such as MS Enterprise library or MVC framework. So if the application depends on other components then you must add those to the applications deployment service package.
Before you build and package your application, verify the following:
Windows azure migration results in a common concern regarding session state. With Windows Azure Web Roles supporting full IIS, the inclination to fall back to tried and tested methods of storing session in-proc, out-proc and in SQL Server is very tempting. Butsince the Windows Azure load-balancer does a round robin routing of the instances and there are no sticky sessions in Windows Azure, you can’t use in-proc session storage. Moreover, a VM instance can get recycled due to a host or guest upgrade apart from the regular code upgrades.
It is recommended to use the following ways to store sessions in Windows Azure web roles
In Windows Azure, the web.config file is deployed as a part of the service deployment package. Due to the stateless nature of the VM instances in which the application’s config file resides, changes to the web.config file on running instance will render the application to not work properly. This is because these changes wouldn’t be synchronized across all of the instances of the role and wouldn’t be available to the new instances. Changes to the web.config file require a new deployment service package to be created, and a new deployment to be pushed to Windows Azure. To effectually configure we recommend you migrate the application configuration settings to hosted service’s ServiceConfiguration.cloud.cscfg file in the Windows Azure deployment project.
An application migration to Windows Azure would require that the authentication process still function seamlessly. Windows Authentication is not available “out of the box
We have plans which will meet your needs, and if not we can tweak them around a bit too!