As I mentioned in my previous post, I spent 3 days last week on a Windows Azure Training Course, unfortunately this meant that I missed out on all the fun that was had on #comday.
One of the most common questions I heard at PDC 08 after Windows Azure was unveiled was around the overlap of functionality between Windows Azure Storage and SQL Data Services (SDS) – why are Microsoft offering two different data base solutions in the cloud, that have so many overlapping features? Which one should I use? What are the benefits of the two different systems? I know I was asking these questions – especially as I was quite familiar with SDS – thanks to our very own Jamie Thomson.
I couldn’t really give these questions too much thought at the time as one of the main problems of PDC is the shear volume of information that’s thrown at you (well, it’s also the reason you attend). This course gave me the breathing room to really start thinking about ramifications of what was presented at PDC.
The reason there is a lack of clarity of the differences between the two systems is simply the use of language to describe the Azure Storage Platform; Microsoft have tried to use terminology that existing developers will understand in order to reduce the fear of the complexities of dealing with Cloud-scale architecture and development.
The Azure Storage Platform is simply and elegantly designed to allow new massively scalable Web Applications and Web Services to be produced. SQL Data Services allows your to run more traditional relational databases (that are essentially not cloud scalable, due to the intrinsic relational behaviour) and in the future more standard SQL Server features such as Reporting, BI etc will be available. SDS will allow companies to migrate existing applications on to this platform (although it is very unlikely this would be a trivial migration).
Hopefully this distinction is quite apparent, but the terminology of the Azure Storage Platform still muddies the water. Microsoft are using familiar terms in order to keep developers in their comfort zones, but unfortunately this is doing the underlying platform a disservice as it does not correctly convey, the scope, grandeur or reason for it’s overall Architecture.
The Azure Storage Platform consists of 3 services – Tables, Blobs and Queues. These are familiar enough concepts for most developers. The problems arise when these services are compared either to the services in SDS or more importantly, when they are compared to the artefacts that most developers know.
Azure Tables are not tables as we know them. Blobs are not blobs as we understand them and Queues, well they are not strictly Queues at all. I’ve always been slightly obsessive about the use of language to accurately describe concepts in code – I constantly have Wittgenstein’s quote “The limits of my language means the limits of my world” going through my head and most people know to steer well clear of mentioning the C# keyword var near me (it should be named infer btw).
If these artefacts were renamed as follows, it might make the Azure Storage Platform picture a little less hazy and reduce collisions with SDS:
Tables = Entity Repository
Blobs = Binary Entity Repository
Queues = Dispatcher