Windows Azure 101 – Primitives and Application Patterns – Playing Mendeleyev

Windows Azure’s primitives are very simple, but as in many other things, the power comes from the combination of these simpler primitives to create more complex things.

Look around and see how many things can be assembled from a little more than 100 “simple” elements.

In Windows Azure,  there are essentially 2 types of building blocks: code hosts blocks and persistent bocks   

The code hosts run (your) code, the persistence blocks store data.

There are 2 types of Code Hosts:

1. Interactive: ASP.NET & WCF
2. Non-interactive: Worker

The interactive building blocks, whether it is a human initiated interaction (ASP.NET) or a programmatic interaction (WCF), is what is referred in Windows Azure terminology as a “Web Role” .  The web role is specialized in “request – response” types of interactions. A user or a program submits a requests, the request is received, analyzed and processed, then a response is sent back. The goal is to process a lot of these concurrent requests and to keep the time between a request and a response as small as possible.

The non-interactive building block is known in Windows Azure as “Worker Role”, and it is the classic background processor. 

There are 3 persistence building blocks. All of them store information, but have specialized functions:

1. Table: stores records with properties
2. Blobs: stores “things” with associated metadata
3. Queue: stores strings with FIFO semantics for retrieval

That’s it.

 

So let’s explore what you could do with this.

A relatively simple web site, like a simple blog engine would be this:

 

The front end web role is the app itself: pages, views, controllers, (whatever you use for the logic of the app). All operations (reads/writes) against the store where posts, comments and images would be stored are synchronous.

Adding one block will give you an RSS feed (e.g. using Syndication APIs in WCF):

 

And now you can independently manage (e.g. scale) your web viewers from those using an aggregator.

Now let’s imagine you’d like to create a heat map similar to the one you see in my blog, showing where are your readers are located. One possible way of solving this calling a components in the RSS or Web nodes providing as input the IP address of the requestor. The component would then lookup somewhere the country or region associated with the IP address and add one to the counter of that specific country/region. This computation will take penalize the request/response for something that the reader is not necessarily interested in. Besides the lookup IP/country might depend on an external call to another service, with even further penalties.

A better solution would be to offload these to another (background) process that con compute the information with minimal cost to the original request:

 

Now the front end nodes will only pay the cost of writing to a queue. The lookup/conversion/heat map generation is done in the background by the worker. You can imagine dynamically creating new instances of the worker if the queue gets too long. Anything that can be postponed for a while, can be pushed to an asynchronous worker for processing (e.g. reporting, analysis, etc)

These are just 6 elements in Microsoft’s larger table of elements for cloud development (.NET Services, SQL Data Services, etc).

These patterns are of course well known (and old :-)), but are proven. Windows Azure gives us a nice way of implementing them plus a way of managing them once they are deployed.

 

Technorati Tags: Azure

Comments

• Anonymous
  April 01, 2009
  Very Good articulation of Azure implementation

• Anonymous
  May 05, 2009
  very simple but effective especially your use of graphs. awesome stuff

• Anonymous
  May 13, 2009
  Estoy leyendo un post del bueno de Eugenio Pace Windows Azure 101 – Primitives and Application