In my last post I described how to configure your machine to get started developing Windows Azure applications.  We built a simple web role (web site host) and took a look at what role the development fabric played in developing a Windows Azure application.  As soon as we try to build more than the most basic web application we are going to have to start considering our storage options.  Following is a high level overview of the four main storage options.  More details for each option will follow in separate posts.

Table Services : The table service is designed to store non-relational entity type data, serialized DTOs for example.  Redundancy is built in. The size of each row of data is limited to 1 MB and there are some fairly restrictive rules around what types of data may be stored in the table.  We should consider using the Table Service rather than a relational database to persist our data.  Not everything has to be stored in a relational database.  If you can keep your entity relationships simple, live without the joins and manage the relationships yourself, Table Storage looks to be a more simple, cost effective, and scalable approach.  Consider using table storage instead of a traditional database and there is even an ASP.Net session provider available in the SDK that uses table storage.

Blob Storage : There are two kinds of blob storage.  Block Blobs are designed to store up to 200GB of binary data and are optimized for streaming.  A Page Blob can store up to 1 TB of binary data and is designed for random access.  Like table storage, redundancy is built in.  This storage mechanism is ideal for Streaming videos, waves, images, or working with random access files such as fixed length field flat file

Queue Service : The queue service supports 8 KB XML messages and also has redundancy built in.  We are not going to let the size limitation scare us, the intention is not to allow us to put large binary objects on the queue for processing rather the intent is that the message would contain some sort of instruction and if need be the message can reference some object already in storage via a key (the message just contains a pointer to the object we want the worker role to act upon).  The key with using a Queue is this is not a chatty interface this should be used more as a  fire and forget.  Queue messages should be communicating a task the sender wants performed, not performing some type of query that requires a response.

SQL Azure : For the sake of this post we can say SQL Azure is similar to the Sql Server we know and love and that it is designed to store and mange relational data.