Nov 052009
 

In my last blog, I wrote how Windows Azure could benefit the customer by decoupling the application from the infrastructure and allowing the customer to concentrate on his application logic alone. So this time I decided to blog about the technical implementation of Windows Azure. I am new to this, so please bear with me if its not detailed enough Here is a diagram showing the architecture of how Azure works azure1 As you can see in the diagram, Windows Azure separates the application from the underlying hardware. There is a fabric controller which is an intermediary between the application and the hardware. This fabric controller internally uses Services to perform many activities like Load Balancing. The Fabric also monitors the state of the servers i.e. in case a Server fails, it internally switches the VM to another server in real time. i.e. no downtime is involved. The servers installed in the data center are not high end machines. They have medium capacity processing power and no RAID setup

One more important component of Azure is the Storage Services. Storage in Azure is done in three forms – blobs, tables and queue. Why we need this kind of storage is that the storage needs to be available to be copied to multiple VMs on the fly. The simplest way to store data would be in the form of blobs going to a maximum of 50 GB. However, we may need a more structured data handling mechanism at time. Here is where tables and queues come in. Tables are hierarchical data structures and not relational ones. They are indexed tables which are queried by LINQ rather than SQL. These tables can reside in several servers at the same time.  Also to ensure data is not corrupted, this data is stored in three different locations. This more than compensates for absence of RAID setup in the servers.

Queues are somewhat different than both than blobs and tables that they are uses as a means of communication. Suppose you have an application for downloading and playing MP3 songs. For this, any request for a particular song would be stored in a queue. This will be read by a server and processed and removed from the queue. The queue system decouples the front end from the back end and as long as both are able to understand and process queue messages, they can work irrespective of the technology.

Well thats it for today. More to follow about Windows Azure services.