Windows Azure Distilled - A Programmer's view

The launch of Windows Azure has coincided with the launch of the entire cloud computing initiative from Microsoft which makes a lot of business sense but it also makes it hard to differntiate the individual parts of the initiative, here’s my understanding so far.

Windows Azure

This is the base platform that provides a generic cloud computing platform for developers to host applications on.  Azure basically offers two core services,

Compute Service

This is what people would normally associate with cloud computing. You write an app that conforms to the cloud hosting requirements and then deploy it to the cloud where it can be managed and scaled as per the load and performance requirements. Currently there are two types of compute services that can be deployed on Azure

Web Role - This currently is a WebForms ASP.Net application, but looks like support for ASP.Net MVC and other languages are in the works too. This is just like hosting your application with a hosting provider except that you get load balancing, failover etc. for free. One important caveat here is that the load balancing does not support sticky sessions(as of the CTP) which is a good thing but it does require the developer to use the storage service to store session data.

Worker Role - This is more like a Windows Service that is deployed on the cloud, it can make outgoing connections but incoming connections are disallowed. But again you get the benefits of load balancing and failover.

The compute services are different from other similar cloud computing options available because it does not require the developer to supply a VM image (unlike Amazon EC2) of the application environment to host,  instead the applications run in VMs that are built and maintained by the Microsoft Data Centers that host the applications.

This decision definitely has it pros and cons, it's good because

- No licensing costs for the OS

- No need for updating of the VMs as the applications evolve

- Simpler deployment strategy

- API available for management of service instances and for reporting on application health

on the other hand

- it does restrict the flexibility of what software and services can be accessed from the host VM

This diagram from MSDN gives a nice overview

All though in reality the deployment internally looks like below with IIS7 and Windows Server 2008 VMs.

Storage Service

This is the second part of the base Azure platform and is the equivalent of Amazon S3, SQS and SimpleDB all rolled under one name. The equivalents in the Storage Service are called,

Blob - For storing binary data, most commonly file streams.

Queue  - For reliable persistent messaging. I found it strange that it was lumped with the storage services because the primary purpose of this seems to be inter service communication between the applications running in the cloud. 

Table - For storing tabular data, different from traditional database tables though.

The important thing to remember here is that these services are available to any application that can talk over HTTP so WPF, WinForms, and non-cloud ASP.Net applications can make use of the storage services as well and benefit from having their data stored in an easily scaled environment. The storage services expose a RESTFul API which makes it easy to access these services from any platform that can talk over HTTP but ofcourse if you're using .Net you get some builtin support from the framework.

The developer story for Windows Azure is as good as anything else from Microsoft, the SDK includes tools to simulate both the compute services and the storage services on your development box, further with the VS addin you can deploy your cloud application straight to the Azure hosting platform, talk about ease of deployment. Here’s a quick overview of the important tools included in the Azure SDK.

Development Fabric - Simulates the Azure Compute Services (aka Azure Fabric) on your dev machine complete with a load balancer and failover monitoring.

Development Storage - Simulates the Azure storage services on your dev machine, the CTP implmentation requires SQL Server 2008 Express but you can also work with SQL Server 2008 if you want.

CSPack - Command line tool that prepares a service for deployment either to the Development Fabric or to the Windows Azure Fabric.

CSRun - Command line tool that runs a service (generated from CSPack) on the Development Fabric.

So the development cycle for a Azure app consists of developing locally using the Development Fabric and Development Storage and then deploying to the Azure platform when ready.  Deployments would not normally bring down the sites because the instances are load balanced and are not sticky. 

The other good thing is that services can be configured manually be editing the service configuration file or programatically by accessing the ServiceHosting API at runtime, so no redeployment is required if only service configurations are changed (which includes things like number of instances to run).

That’s basically the core Azure platform, the rest of the stack (.Net Services, SQL Data Services and Live Services) are cloud applications built by Microsoft on top of the core Azure platform. Again all these applications expose their API in a RESTFul manner as well making them open to both any technology that can talk over HTTP.

Personally for me the Windows Azure SDK section from MSDN and this document from David Chappel were the most useful pieces of documentation to understand the entire stack.