Overview of Windows Azure

Windows Azure isn’t particularly “on-topic” for this blog, but hey, just because I’m a client guy doesn’t mean that I can’t show any interest in other technologies, right? Manuvir Das presented a session on the subject at MIX09, and since I’m sat at home with a heavy cold feeling sorry for myself, I thought I’d catch up on some of the sessions that I’d missed via the free online MIX09 recordings.

(In passing, I’d love to know whether these kinds of detailed session notes are helpful to you – feel free to add a comment below or send me a private note.)

What is Windows Azure?
In a nutshell, Windows Azure is an operating system for the cloud.

As an application developer, one can think of an operating system in the following ways:

• an application execution environment that acts as an abstraction over the hardware;
• a shared file system with access control;
• an allocator of resources from a shared pool;
• a platform that supports powerful programming models;
• a model that supports interoperation with other systems.

Why do we need a new operating system for the cloud? What’s wrong with the existing model?

The reality is that running cloud-based services presents many unique needs (as an example, consider a popular website like Flickr or Hotmail). Any service that is provided at scale is distributed across servers in one or more geographically-dispersed datacenters. It is expected to be available 24 hours a day, 7 days a week: a failure in any individual piece of commodity hardware needs to be automatically and silently managed without external disruption. Servers need to be upgraded to new software and hardware without taking the whole service offline; the service also needs to be able to support sudden increases in traffic or storage requirements seamlessly.

All these demands mean that infrastructural concerns become an overriding constraint in providing the service. We need software that can manage and abstract these problems – specifically, an operating system that spans and controls a set of connected servers, providing an execution environment, a shared file system, resource allocation, administrative tools and so on. In this world, the ideal is a utility computing model that presents the datacenter as having essentially infinite scale available, with the application developer paying only for the actual resources consumed.

As an operating system for the cloud, Windows Azure provides four facilities:

1. Development. An environment for developers based on familiar concepts and frameworks.
2. Computation. A virtualized service execution environment running on cloud-based hardware.
3. Management. A policy-based infrastructure for controlling the way services operate.
4. Storage. A scalable set of cloud storage services for data.

Development and Computation
In building Windows Azure, the primary goal was to create a rich and familiar programming experience. You can write code using .NET, PHP or native Windows code, using Visual Studio or even Eclipse. The SDK provides a simulated cloud environment (known as the development fabric) that a developer can run locally to build and test an application, along with tools to package the application for production deployment: it’s important to note that there is no difference to a developer between the local and cloud-based environments.

Newly introduced at MIX09 is support for full-trust application execution, allowing you to run any native code via P/Invoke (as well as more complex .NET applications); you can also now use FastCGI as a way to offer native handlers for your application. Another new addition that will be available shortly is geo-location, allowing you to target your services to one or more locales and ensuring that data and storage are co-located for performance optimization.

Windows Azure is now running in production on datacenters across the world. As part of the session, Manuvir demonstrated two Windows Azure-based demo sites, Botomatic and Tweval, that build on Twitter to provide live session feedback.

Management
The overriding constraint in Windows Azure was to ensure that services can be managed automatically. When you develop your service, you also define a model using XML that describes the service topology and size (number of instances), the resources required (e.g. disk sizing), health constraints (how Windows Azure should know when a service is “unhealthy”), and other configuration settings. When you deploy the service, Windows Azure takes care of identifying one or more virtual machines to run the service, setting up load balancing, creating an entry point for the service and then ultimately monitoring the service for health.

Storage
Windows Azure provides a number of simple abstractions over the underlying cloud-based storage: blobs for large items of data, tables for handing service state, and queues for communicating between services. Additional abstractions over the storage will be exposed over time. One important caveat is that Windows Azure doesn’t support automated geo-replication in the current production environment (although it is coming): you need to manually deploy your data to different locales if you need it to be geographically dispersed.

What if you need a relational database in the cloud? The Azure Service Platform will provide a SQL Server-based cloud relational store, called SQL Data Services; the separate MIX09 session on this topic provides more detailed information on this aspect.

Conclusion
Beyond the core functionality that Windows Azure provides, best architectural practices remain important. The platform is designed to encourage best practices: stateless computation with durable storage, with web and worker roles co-located and communicating over queues.

Windows Azure is currently in CTP, offering free usage with quotas; an updated technical preview was released at MIX09, with regular updates expected through 2009 culminating in a commercial release by the end of the year.