Windows Azure:
O Compute @ $0.12 / hour
O Storage @ $0.15 / GB / month stored
O Storage Transactions @ $0.01 / 10K

Now at first glance this doesn’t look too bad. However, as pointed out in a number of blog posts and forum threads (such as this one on the MSDN Azure Forum), the actual bare minimum cost of running a website comes to about $86.40 per month. This is for a site consisting of a single web role and a single backend worker role (regardless of amount of work actually performed by either) and could actually be $172.80 per month depending on whether a single web role and a single worker role count as two separate instances.

Now for the project I was working on this simply isn’t feasible, I was experimenting with an idea and wanted to try out the data driven site on Azure as it provided the means to have an ASP.NET powered site with background work being performed as required, on demand and on schedules. Unfortunately as it was an experiment there was no guaranteed income from it and so would very quickly have become a fairly expensive side-project to be running in my spare time.

Initially I had paused the project pending any further news about the Azure pricing, but as you can see from that forum thread some details are not 100% clear yet. As it has now been a couple of weeks I’ve decided to partially continue work on the project but am currently segregating my storage and other Azure related parts so that I can easily swap these out for an alternative platform without too much wasted work… We shall see!

One requirement of Azure table storage is the use of a PartitionKey and a RowKey, both of which when combined uniquely identify an entity in the Azure table. As the use of a good PartitionKey can lead to many benefits in terms of scaling it is a good idea to use a useful property of an object as the partition key, however the partition key must be called ‘PartitionKey’ which leads to a situation where an important property within a class is simply called ‘PartitionKey’ and to know what that property represents you have to either remember it or keep checking your comments.

At first I attempted to simply create a property to wrap the partition key like so:

public string Name
{
    get
    {
        return this.PartitionKey;
    }
    set
    {
        this.PartitionKey = value.ToString();
    }
}

but unfortunately due to the way that the Azure table builder works this means that the created tables actually have duplicated data stored, the same data under the column ‘Name’ and ‘PartitionKey’.

After what was actually a surprisingly quick search around on Bing I found out that while there is not really a proper way to achieve what I wanted, there is a simple work around which is to set the created property to be internal.

internal string Name
{
    get
    {
        return this.PartitionKey;
    }
    set
    {
        this.PartitionKey = value.ToString();
    }
}

This prevents it being seen from by the Azure table builder and so does not duplicate the properties when creating the table. However as you may have guessed by specifying these as internal they are not accessible from a different project and so must be in the same project as the code using them.

Alternatively if you need to share them across projects then you could create a wrapper for the class… I’m going to give this approach a try unless anyone can think of a better way?