Minimizing code impact of migrating to Azure Blob storage

Question

I'm attempting to migrate fairly complex application to Windows Azure. In both the worker role and web role there are many instances where the application saves files to a local file system.

Here's an example:

string thumbnailFileName = System.IO.Path.GetDirectoryName(fileName) + "\\" + "bthumb_" + System.IO.Path.GetFileName(fileName);

thumbnail.Save(thumbnailFileName);

and another example:

 using (System.IO.StreamWriter file = System.IO.File.AppendText(GetCurrentLogFilePath()))
   {
     string logEntry = String.Format("\r\n{0} - {1}: {2}", DateTime.Now.ToString("yyyy.MM.dd@HH.mm.ss"), type.ToString(), message);
     file.Write(logEntry);

     file.Close();
   }

In these examples we are saving images and log files to file locations specified in the app.config. Here's an example:

<add key="ImageFileDirectory" value="C:\temp\foo\root\auth\inventorypictures"/>

I'd like to make as few code changes as possible to support Azure blob storage in case we ever decide to move back to a more traditional hosting environment and more generally to reduce the potential for creating unintended problems.

Based on this post I've decided that Azure Drive is not the best way to go.

Can someone guide me in the right direction (ideally with an example)? The best solution in my mind would be one that only requires a change to my config file. But I'm guessing that is not realistic.

score 3 · Accepted Answer · answered Jul 21 '11 at 17:13

Indeed, you want to use Azure Blob storage to save your files.

As for your coding question, consider creating an interface, call it IFileStore:

public interface IFileStore
{
   void Save(string filePath, byte [] contents);
   byte [] Read(string filePath);
}

Then you create 2 provider classes, one for the file system, and one for Azure Blob storage.

The file system provider can implement the save function like this:

    public void Save(string filePath, byte [] content)
    {
        File.WriteAllBytes(filePath, content);
    }

    public byte [] Read(string filePath)
    {
        return File.ReadAllBytes(filePath);
    }

As for the Azure Blob provider, you will have to derive the storage path based on the filePath passed in to you.

score 2 · Answer 2 · answered Jul 21 '11 at 17:22

Generally

For your storage, I'd recommend using Blob and Table storage - this allows multiple instances to access the storage simultaneously. If you want to assist with making the code portable, then I'd recommend abstracting your code behind interfaces/APIs (see @Philpp's answer).

e.g.

for your log file example, then table storage might be the best thing to use
for your image files, then blob storage might be the best thing to use

If you really want to use AzureDrive

I'd only recommend using AzureDrive if you are only ever going to deploy a single instance of your role - otherwise you will end up fighting problems with sharing files across multiple instances (and remember that only 1 instance can mount with write access at any one time)

If you are operating with a single instance, and if you are only storing temp and log files, then you could also look at using local storage instead of azure drive - it's much simpler and cheaper to use than blob storage. e.g. One possible specialist alternative for your log file example is that you could consider using local storage alongside Azure Diagnostics-controlled uploading of that local storage to Blob storage.

Minimizing code impact of migrating to Azure Blob storage

2 Answers2