SlalomWorks

The Windows Azure Platform is composed of different building blocks that you can use to build your cloud solution.  As far as choosing how to store your data in the cloud, you have options.  Windows Azure Storage has different types of durable, scalable storage for blobs, tables, and queues.  A totally separate offering, SQL Azure, provides a relational database solution in the cloud.  I will touch briefly on these options, and then give some guidance.

Windows Azure Storage: BLOB Storage
BLOB Storage provides a place to store files and associated metadata.  It can be compared a file system, where you can create containers (folders) to place large files.  It is a great place to store images, documents, videos, backup files, archived files, and the like.  The Windows Azure Content Delivery Network can sit in front your BLOB storage to provide better performance and user experience for systems using BLOB storage.  Custom domain names can be associated with Azure storage accounts now as well, so you could literally have a user hit http://www.myapp.com/music/artist/song.mp3 and have that delivered through the Azure CDN.  This offering will be in direct competition with Amazon S3 and its CDN.  Jeff has a great post about the  Amazon Simple Storage Service.

Windows Azure Storage: Table Storage
Table  Storage provides structured storage in the form of tables.  Tables hold entities and entities have properties, but there is no schema enforced on the storage side.  Table storage is designed for systems that need to be scalable.  These tables can scale to billions of entities if need be, with your data being partitioned transparently across servers by the storage platform.  It is up to the application to define how data is partitioned, a decision that should not be taken lightly.

Windows Azure Storage: Queue Storage
Queue Storage and its API provides an out of the box message queue for an application.  The queue service and storage provides a great way to accomplish asynchronous processing, something to always be thinking about when developing for the cloud.  Azure Queues can be the bridge between a Web Role and Worker Role, or even and on-premise system and a cloud system.

SQL Azure
SQL Azure provides a relational database in the cloud, and a very familiar experience for developers used to building databases with SQL Server.  A large number of features in SQL Server are supported in SQL Azure, and a few are not yet.  The key is that your SQL Azure database will have a fixed size.  Currently you can create a database of the 1 GB or 10 GB capacity.  Here is a post of mine that talks more about SQL Azure and how to get started.

Making Choices
So you are developing a new application in the cloud.  With these options available to you, what do you use?  After developing several application on the Windows Azure Platform, my answer is a hybrid approach.  Your choice depends on the data you are storing.  In my solutions, I take advantage of all of these offerings to achieve the best results for my app.

Let’s take one of the current applications I am working on as an example.  It’s a pretty standard web application, with a database backend.  For relational data, we are using SQL Azure.  But gone are the days of storing files, images, etc in a SQL database.  We use BLOB Storage for those, where we will be able to take advantage of the CDN offering.  We even plan to explore CMS functionality leveraging BLOB storage.  We do a lot of logging in our application, and are using Table Storage to store this data.  We don’t have to worry about logs filling up our SQL Azure database.  Our logs can scale without impacting our vital application data.  Finally, we use Queue storage for triggering asynchronous work, minimizing wait times in our UI.

If you feel that your relational data is going to go beyond the current 10 GB limit of a SQL Azure database (after you have removed anything from your SQL Azure database taking up space that could be stored in another medium), then Azure Table Storage is probably a better way to go.  This system is truly designed to allow applications to scale very large.  Having to build partitioning logic into your application because you have to take on another SQL Azure database is something you could have avoided by architecting against Azure Table Storage from the start.

So the key is using these storage offerings where the make sense.  Don’t be afraid to use both SQL Azure and Windows Azure Storage together.  Stay tuned for more posts that delve deeper into these topics.

- Joel