Windows Azure Services Platform gives wings to .Net

Microsoft intends its new Windows Azure Services Platform to be a serious cloud computing platform for a broad range of developers and scenarios, from lone developers starting up a new Web-based company on a shoestring to large teams of enterprise developers looking for high-performance, highly available, and scalable Web sites, computing, and storage. A few years out, Microsoft wants Azure to be seen as the preferred location for enterprise data, not as a business risk. It's off to a good start.

There's a tremendous amount of capability being presented in the Azure CTP (Community Technology Preview), and there's more to come. It goes beyond simple Web hosting to a flexible architecture designed to automatically enlist additional resources in response to demand. There are capabilities here that I haven't seen in competing cloud offerings -- for example, workflows. The Azure team has picked and chosen existing Microsoft technologies -- virtual servers, the .Net Framework, IIS, worker processes, databases, queues, enterprise service bus, workflows, authentication, and so on -- and adapted them to the cloud.

One very promising note is how these services are tied together. The Microsoft of 10 years ago would have created proprietary interfaces to exclude its competitors from taking advantage of its technologies. The Azure team used open standards: REST, SOAP, Atom, and the like. This inclusive choice opens the Azure services to easy integration with almost any programming language and operating system.

Another promising note is how, while breaking new ground, the Azure team made the programming model familiar to developers who have worked with the .Net Framework. You don't have to learn a new programming language or IDE to work with Azure. If you know Visual Studio and C# or Visual Basic .Net, you're good to go, now with relatively little effort. Using other .Net languages and tools is possible but not as well documented. Although using unmanaged code is not yet allowed, it will be in the future.

It took me a couple of weeks of dabbling with Azure an hour at a time to "get it." Part of my problem was that I was overwhelmed by the amount of seemingly independent functionality available. Once I realized that what I was learning was a carefully designed, scalable SOA tied together with RESTful APIs, it began to gel for me. I would expect that any moderately experienced .Net developer with some SOA experience could be somewhat productive with Azure after a few days of concentrated work and fluent in a few weeks.

Four pillars

The Microsoft Azure Services Platform is a Windows-like cloud computing architecture with four major parts: Windows Azure, which is a Windows-based environment for running applications and storing data on servers in Microsoft datacenters; Microsoft .Net Services, which are distributed infrastructure services; Microsoft SQL Services, which are data services in the cloud based on SQL Server; and Live Services, which access data from Microsoft's Live applications and others and allow synchronizing this data through Live Mesh.

Page Break

A Windows Azure application currently looks a lot like an ASP.Net application, although it has some restrictions and additional features. Azure supports Web roles and Worker roles; a Web role is like an ASP.Net site, while a Worker role is a background process, like a .Net-based service. Roles may be given multiple instances, with each instance in a virtual machine under the control of the Windows Azure Fabric; a load balancer makes the cloud of Web instances respond to a single HTTP URL.

Azure stores blobs, tables, and queues for Web and Worker roles in a replicated storage instance; these are addressable by a RESTful URI (uniform resource identifier). Azure blobs (binary large objects) are very loosely organized into containers and blocks and may have associated metadata. Azure tables are hierarchically organized entities with properties, which may be queried using LINQ syntax; they are emphatically not relational database tables. Queues are used for reliable communication between Web role instances and Worker role instances, typically to post work items for processing.

.Net Services include the .Net Access Control Service, which controls access to Web resources using security tokens; the .Net Service Bus, which is a discoverable registry of Web end points; and the .Net Workflow Service, which is a sequential workflow controller. SQL Services currently includes only one of the several planned components: SQL Data Services, which is basically a hierarchical store of authorities, containers, entities, and properties addressable using REST or SOAP and either a LINQ-like language or ADO.Net Data Services. SQL Data Services may be based on SQL Server, but it isn't used like SQL Server.

The Live Framework enables access to Live Services and also to Live Mesh synchronization, using the Live Operating Environment (see diagram). In the interest of brevity, I'll defer any further discussion of Live Services to a future article or blog posting.

Development

Currently, Azure development is done on Windows Vista SP1 or Windows Server 2008, using the various Azure SDKs and tools plus Visual Studio 2008 SP1. Getting started is a multistep process: You need to apply for the preview, then download and install the prerequisites, SDKs, and tools. If you're accepted for the preview, you'll receive tokens via e-mail that you can redeem to create instances of the various services.

Once you've installed everything you need and started SQL Server and IIS, you can test out the Azure development environment by building and running applications supplied with the Azure SDK locally. If everything is working correctly, a local fabric is created along with local blob, table, and queue storage.

Page Break

From the supplied templates, you can create a new Visual Studio project for a cloud service with Web and/or Worker roles, a cloud sequential-workflow service, and Live Framework mesh-enabled Web applications with or without Silverlight support. I would say that getting to "Hello, World!" with an Azure Web role might be the second most complicated "Hello, World!" application I've seen, after Microsoft's own Workflow version, but it really only requires adding one line of code or HTML to the project generated by the Visual Studio template.

This snapshot of the developer portal for Azure hosting, storage, and Live Services shows where I uploaded, tested, and promoted my iwhello1 application from staging to production. At the time, it was live at iwmh1.cloudapp.net and returned "Hello, InfoWorld" to the browser. This snapshot shows a management page for .Net Services and SQL Services.

If you use Azure storage, you need to be aware that the URIs are different for addressing storage services in the cloud and in the local fabric. Consequently, development proceeds in steps. You start by running locally, then you change the storage URIs to move to mixed mode, running the application in the local fabric against cloud storage. Next, you publish your application to the cloud, test it at a staging URL that includes a GUID (globally unique identifier) as part of the address, and finally promote it to a production URL.

One thing Microsoft has always been good at is providing sample code for developers, and Azure is no exception. The Azure SDK has nine samples, although two of them are basically "Hello" apps; the Microsoft .Net Services SDK has samples that cover every service it offers both in C# and VB; the Live Framework SDK has samples for a variety of scenarios and libraries for .Net, JavaScript, and Silverlight; and the Azure Services Kit has 11 hands-on labs with setup instructions, a lab manual, and lab files. I would advise most new Azure developers to work through all the labs, if time permits, then dip into any relevant samples.

Competition

There are many ways to run applications in a cloud. Amazon EC2 running a Windows Server 2008 image is probably the closest equivalent to Windows Azure and likely to be the top alternative to Azure for experienced ASP.Net developers who need capacity on demand.

Developers with enough experience to be comfortable in multiple languages and multiple operating systems have more choices: not just Amazon EC2 running other images (such as Ruby on Rails on Linux with MySQL) but also Google App Engine (Python/Django), Force.com, and the like.

Given Azure's preview status, it's difficult to say anything meaningful about its competitive position. We don't yet know what it will cost, and it has no track record for reliability at this point. What we do know now is that it's a well-thought-out cloud computing architecture that should be easy to learn for existing ASP.Net developers.