New Azure functionality that would increase app migration to the cloud

Over the past week I have been playing with migrating a couple of ASP.NET apps to Azure.

The first thing I do is make sure that the DB being used its compatible with the Azure feature set. If this step doesn't work then there is little point persisting with the investigation.

The next problem with apps that have a suitable database is that the App_Data folder, so heavily used in many .NET apps and rightly so as content here is not served by IIS, it's the place for all your..well...er  app data! In Azure the App_Data folder is read only though.

Microsoft recommend running a minimum of 2 Web Roles in any deployment. In fact the SLA does not take effect unless you do. The Azure system will make sure these 2 roles are not hosted on the same hardware, so giving you hardware redundancy in the event of a host going down, great stuff..
As soon as you are running 2 instances of your app, writing to the App_Data folder becomes pointless anyway as the next user request may be routed to the other instance and the change would not be visible.

So this is understandable but what it does is immediately make all apps that write to this folder unsuitable for migration to Azure without significant coding changes.
So you decide that you want to make your app to work on Azure. What to do?, you have to rewrite it to not write anything to the local storage but to store everything elsewhere.

Steve Marx has created his own Web Role from a Worker Role and cleverly used it to serve web content by using Hosted Web Core internally. He got it doing 2 cool things, running a site using content from a Azure Drive, and also using Blob Storage to host the actual content of the site and sync it to all running instances.

Steve himself is keen to point out that this is an interesting exercise but that use in a production environment is not recommend. As he points out, you then lose all the built in functionality of the Web Role and have to manage IIS yourself etc.

However it's close to what I think we need in Azure, the ability to have a read/write area, probably App_Data that is persistent but can cope with many instances, essentially a cross between the Azure Drive example (which should be read /write already) and the Sync from Blob example but maybe just for the App_Data folder.

In this way, when one Web Role changes something in App_Data, the Role itself syncs this to Azure Blob Storage (so is persistent and can be remotely managed) and raises an event that makes the other Web Roles update their folders. They could cache the content locally for speed and only overwrite when it changes.

While this is probably possible by modifying the HWC examples Steve has created and creating a virtual directory, mapping App_Data to it (I'm not sure this is possible), and creating a 2 way sync between Blob Storage and other instances, I think this would be a good feature to build into Azure itself. With it Microsoft would instantly increase the potential number of existing apps that can be migrated to Azure without modification.