Azure Canonical Application Architecture

While working with a customer last week at our Microsoft Executive Briefing Center (Microsoft EBC), one of the things we need to do was find a simple way to whiteboard the architecture.  We walked through a lot of variations of application patterns, but the customer ultimately wanted to see one code base running on Azure that could support multiple clients (such as desktop, phone, browser, etc.)   We found a model that was pretty straightforward and allowed us to easily map the customer’s scenario onto the Azure platform.

Once we had a model, it was a lot easier to drill down on things such as why SQL Azure vs. Azure Storage or how to flow claims or how to partition the database.  It’s like a backdrop that you can overlay or drill down on security, performance, manageability, etc.  It helped us quickly explore paths without getting into weeds and keeping the big picture in mind.  It also helped us figure out where target some of the key architectural spikes.

Here are some of the models we walked through on the whiteboard:

Baseline

Azure Storage Example

SQL Azure Example

Comments

• Anonymous
  July 04, 2010
  Hi, Just wondering - how do you deal with the fact that Azure Queues do not guarantee message to be delivered only once?

• Anonymous
  July 04, 2010
  @ Rinat -- Good question.  Here are some strategies from the Windows Azure Guidance at msdn.microsoft.com/.../ff803372.aspx: If your message processing method is not idempotent, there are several strategies that you can adopt to stop the message recipient processing a message multiple times:

• When you read a message from a queue, you can use the visibilitytimeout parameter to set how long the messages should be hidden from other readers (the default value is 30 seconds). This gives you time to make sure that you can process and delete the message from the queue before another client reads it. Getting a message from a queue does not automatically delete it from the queue. It is still possible for the visibilitytimeout period to expire before you delete the message, for example, if the method processing the message fails.

• Each message has a DequeueCount property that records how many times the message has been retrieved from the queue. However, if you rely on this property, and only process messages that have a DequeueCount value of 0, your application must guard against the possibility that a message has been dequeued but not processed.

• You could also add a unique transaction identifier to the message and then save the identifier in the blob's metadata properties. If, when you retrieve a message from a queue, the unique identifier in the message matches the unique identifier in the blob's metadata, you know that the message has already been processed once.