On the second day of Windows Azure Platform Christmas my true love gave to me the Storage Service.
What is the Storage Service?
Well, it does exactly what it says on the tin. The Storage Service provides a way of storing simple Blobs (Binary Large Objects) to a more structured table, as well as providing a way for services in the Windows Azure environment to communicate with each other. You might be wondering why something like communication is banded in this group, the answer is simple, messages need to be stored somewhere
NOTE: To access the Storage Service and all its innards, you need to have a Storage Service Account (Storage Account), which you can sign up for through the Management Portal (http://windows.azure.com)
The Blob Service is used for storing text and binary data and is Windows Azure’s simplest form of data storage.
Accessed via a Storage Account, you can create multiple containers with one or more Blobs. Blobs can store a large amount of data, which can be subdivided if necessary to improve data transmission integrity. They can also have associated metadata, for example storing author information about a particular document, file, .mp3 etc.
The Table Service is used, if you require a more structured storage solution that can be queried.
Not to be confused with relational tables; like in SQL, Azure tables are actually entities with properties and no schema. These properties can have types such as, string, double, int or DateTime. So you’re wondering how to access data from your application. Well, by using a simple query language defined by OData of course More detail on OData can be found here http://www.odata.org/
The Queue Service provides persistent and reliable messaging between other services in the Windows Azure Platform.
One of the main uses for the Queue Service is to provide communication between a Web Role instance and a Worker Role instance; both of which were discussed in Day 1 of Windows Azure Platform Christmas.
An example of this would be a user submitting a compute-intensive task via a website implemented by a Web Role. The Web Role takes the task and puts it into the Queue Service, describing what needs to be done. The Worker Role comes along, picks the task up, processes it and returns the result via another queue or is handled in some other way.
One of the amazing things about the Storage Service is that you can access the data in Azure Storage with an application that might be in your network or somewhere completely different. All that is required is that you access the data in a RESTful way. More detail on the RESTful style can be found here http://en.wikipedia.org/wiki/Representational_State_Transfer
I hope this has given you a quick insight into the workings of the Storage Service.
Tomorrow’s installment: Fabric Controller
P.S. If you have any questions, corrections or suggestions to make please let me know.