This is one in a series of posts on when and where to use a distributed architecture design in your organization's computing needs. You can find the main post here: http://blogs.msdn.com/b/buckwoody/archive/2011/01/18/windows-azure-and-sql-azure-use-cases.aspx
Description:
Some applications lend themselves for the entire architecture to be placed on an outside provider such as Azure. And in some cases, you’re interested in using a Relational Database Management System (RDBMS):
- Web application with fast meta-data search requirements
- Web application requiring high levels of consistency and/or atomicity
- Common-use data, shared among multiple web applications
- Durable data storage for stateless applications
Unless you need the data to be kept local (see the hybrid application use-case), SQL Azure makes a good fit.SQL Azure shares the same logical “backbone” as Windows Azure, so an Azure application that needs structured storage, either exclusively or alongside Blob or Windows Azure Table storage (Key/Value pair, more akin to NoSQL in architecture than RDBMS).
Implementation:
This is actually one of the easiest concepts to display for a SQL Azure architecture. It’s logically the same as keeping the application completely local, with the exception that you don’t have to install or maintain anything. Note that although Windows Azure applications are a common use, you can use any web program to access the SQL Azure database:
Image may be NSFW.
Clik here to view.
Considerations here include the decisions on when to use structured storage for a datum or some other storage. In many configurations, you might want multiple storage paradigms. Here is one such example architecture, although many others are possible:
Image may be NSFW.
Clik here to view.
In this diagram I’m indicating a simple shopping-cart application. A Windows Azure Web Role provides a “front end” or presentation layer to the client. A Worker Role provides computation functions, and the Queue maintains the state information so that the application is scalable. SQL Azure stores meta-data about the items in a catalogue of items a user can purchase, such as name, size, price and so on. This provides fast lookup, and allows re-use of code that existed on an on-premise SQL Server.
Once the item is located, a reference in a SQL Azure column (from a standard SQL query) locates the GUID for the object’s picture, stored in Windows Azure Blob storage, and displays that to the user. The Worker Role moves the information for the customer’s order from the Queue to a Windows Azure Table object.
Of course, you could architect all of these data elements into only one or another kind of storage. In this case, the cost, performance and other characteristics of each data requirement dictated this selection.
Resources:
Storage and their abstractions: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
Image may be NSFW.Clik here to view.
