azurehorizons.com

In Azure we have four main storage options and these are Table, Sql Azure, Blobs and Queues.  This goes up to five if you include local file storage however because of its temporary nature it should not be seen as a serious contender for a storage solution.  Each of the four storage has its own merits but in this blog we are going to look at blob storage. In subsequent posts I will delve further into the blob storage service but for now my main aim is to get you comfortable with what it is about.

Binary Large Objects (BLOBS) are typically large in size and usually are seen as mp3, image or video files but could just as easily be large message attachments sent over a SOA system. Traditional storage solutions have centered around either the filesystem or the database and each of these have suffered from issues of latency, expense of storage and resilience.

In Azure we store blobs on the filesystem but make them accessible either through the rest api or a .net wrapper around the api known as storage client library.  Which one you use is really up to you but I think most .net developers are going to go with the wrapper purely on productivity grounds alone.  The wrapper for example gives you intellisense support within Visual Studio.  As an aside we have Azure Drive,  this effectively makes blob storage accessible through the file system of an instance.  There are two caveats with Azure Drive firstly you can only use it within the confines of the data centre that house the instance to which the drive is attached.  This prevents on premise solutions from accessing the drive, every thing has to be in the cloud.  Also it is attached to one instance and as such other role instances have read only access to it.. so it is limited. This may change.  Its main advantage is speed as it bypasses the whole stage of brokering requests through a rest interface.

One of the main questions you have to ask yourself is how you are going to use blob storage.  You should remember that performance is always going to be an issue with storage and if you are architecting a solution that accesses blob storage then the best performance is going to be a solution that is also within the same data centre as the storage solution.  That said it is perfectly feasible to use the rest based storage as a backup solution for on premise applications.  You just have to be clear about your tradeoffs and what are the important aspects of the solution application.

Blob Storage Fundamentals

All storage solutions are attached to account.  When you create an account in Azure the URI for queues, tables and blobs are associated with that account

The screen shot above shows a storage account I have created in Azure.  Also note some of the properties of this account

We have three URL’s for accessing our storage on one account.  The URL’s default domain is core.windows.net.  This is not set in stone and we can configure Azure to use our own custom domain names by changing the CNAME property.  I will cover this later in a seperate post.  Also note we can specify the data centre we want our storage to be located in, here I have chosen North Europe.  We may have compiance issues concerning where the data is stored that make this a crucial choice.

So how is this all structured within the Azure world ?

The blob file lives within a container that is associated with an account.  The common way of looking at containers is to see them as similar in function as a folder on the filesystem.  Containers are a way of setting access to the blobs within them rather than specifying access permisssions on each individual blob file within them.  There are two settings Private and Public.  Private containers are only available to the person who created the account.  When you try to access the elements within a private container you will be prompted for an access key.  Public on the other hand gives every body read only access but you will need the access key to manipulate them.

When creating accounts it is best to have an account per application.

Developing with Azure Blob Storage

Our article http://azurehorizons.com/blog/2011/06/azure-dynamic-configuration/ shows you how to define a connection strings in the Web.Config equivalent of the Web.config.  It is always best to specify your account settings within config rather than code because it allows us to easily change betewwn environments without having to recompile code.

We are going to show you some examples of creating containers in this article and the next post will look at how to use and manipulate blobs within these containers.

Typical code to create containers is shown below

These would be typical connection string properties within the definition and configuration files.

Once we have these in place we can create a container that will hold our blob files.  Firstly if we are using the sdk version 1.4 we need to have this code in a central location.  Typically for a web role we will have it in a global.asax file.

We will worry about this later but for now just take it as red that we need this code somewhere.

To create a container via the api then we can code the following

Here we are creating the container from the click of a button. We are create an instance of the account using the settings we specified earlier in our configuration.  For development purposes we use the UseDevelopmentStorage = true setting but we would swap that out for our live accounts.

Once we have got our account we create a client instance and then generate the container from the client.  The create method genrates an HTTP request to the BLOB storage service to create the container.  The default permissions on this container will be private.  The same code as above but with container.Delete() will delete the container.  To list containers we simply call blobClient.ListContainers() and bind the results to a control.

As you can see we are interacting with the api in a standard manner, following familiar steps of creating a connection to the underlying storage and then generating what we want from the client connection.

Interacting with the development storage

When we are developing, its nice to see that we are interacting with storage properly.

If you right click the azure symbol in the system tray and choose show storage emulator UI we can see the endpoints of our dev storage and start and shut them down at will.

A nice little tool you can download http://azurestorageexplorer.codeplex.com/.  This tool allows you to view any files added to storage, delete those files and also interact with the account and container from a nifty ui.

We can use this tool to make sure that our code is working and creating, deleting containers and blob files. Remember that in the devfabric world storage is mimicked and Sql Server is used behind the scenes.

This article showed us the basics of creating and manipulating containers, in the next article we will look at manipulating other properties on the container and posting blob files out to them.  This is the taster before the main course !!!