Recently, one of our clients wanted to host a web site on Windows Azure. Our solution would consist of the actual web site and our content management tool to allow for content changes in the web site, so we would have two different web applications hosted on Azure.
One spec was that the web site admin should be able to upload photos and images that would show up in the site. The problem was that Azure doesn't allow for file I/O operations, so you can't upload a file and then save it on the disk.
When thinking of how we could implement this feature, we though of using Azure Storage, which is Azure's way of providing hosted applications with storage space. Included in the Azure SDK is a tool named Azure Drive, which is intended to allow applications to use Azure storage as they would use a local drive, so that they could read and write to Azure whithout changes in their code. The drive is implemented as a Windows Azure Page Blob containing an NTFS-formatted Virtual Hard Drive (VHD).
One limitation with Azure Drive however was that a drive could only be mounted by one VM for read/write access at any given time. So, the admin could upload the images, but the web site (which was a different web application) would not be able to mount the drive and show them.
The solution we came up with was using the Azure storage API directly to manage our files. In effect, using the provider pattern, we created a StorageProvider and provided three provider implementations, a FileSystem provider, for normal fiel system access, a DBFileSystemProvider for storing files in a database, and an AzureFileSystemProvider for storing files in Azure storage.
Having done that, all we needed to do was change the System I/O calls to our provider interface calls in the code, and just like that by changing the web.config our web applications were now able to read and write files in Azure.