Windows Azure Web, Worker, and VM roles demystified

John Joyner says that some IT pros may have avoided possible benefits from Microsoft's Azure because its terminology is geared to developers. Here's a quick take on Azure VM roles and what they can do for you.

Some highly awaited Microsoft Azure features are emerging from beta and becoming available for commercial use. One of these is the Azure Compute: Virtual Machine (VM) role, which is interesting for the possibility of using Azure VMs for a variety of purposes. For some customers, and for some server roles, the price and features (such as worldwide reach of the Azure global datacenters) might be in a sweet spot.

Azure is marketed to software developers, so you have to enter their world to efficiently use the platform. For example, to actually deploy a VM, you "publish" your "VM role application package" to Azure using Visual Studio-not familiar tasks, or a familiar tool for many IT-pros. This might be a reason for the slow uptake (or understanding) of Azure by IT-pros. It was only when the VM role became available for beta testing that I was personally interested in learning lots about Azure.

Windows Azure: A VM for you, with three ways to use it

The Azure platform has a dozen features or more, among these is the Windows Azure Compute instance. Here is a simple key to understanding what "compute instance" means: Each Windows Azure Compute instance represents a virtual server. It can be very confusing to try and purchase an Azure subscription because some unfamiliar terminology is used. "750 hours of a small compute instance" as Microsoft describes Azure pricing, means in more familiar terms "One month exclusive use of a small VM." You can use this VM in three ways, shown in Figure A: As a front-end/web server (Web role), as a back-end/.NET application server (Worker role), or as a VM.

A Windows Azure Project in Visual Studio 2010 lets you create three roles-Web, Worker, and Virtual Machine.
If you have a front-end server role that needs IIS (for example an ASP.NET-enabled website), don't use the VM role, use the Azure Compute Web role, and just upload your website code to the cloud. Azure automation will deploy the website to your Azure VM instances, completely abstracting you from the actual VMs. Microsoft handles the operating system (OS) updating and has a service level agreement (SLA) on the OS availability of the VM instances. This saves you time and money by not having to manage a Windows web server farm, but you experience the full computing isolation and power of your own VMs running Internet Information Services (IIS). Likewise if you have a middleware or backend process server that runs code such as .NET Framework, but does not require IIS for website publishing, you would use the Azure Compute Worker role. Like the Web role, the Worker role frees you from managing the server(s) running the code.

For the Web and Worker roles, Azure supplies the VHDs and hosts the VMs invisibly. You interact with Web and Worker roles programmatically, by just uploading your web server and/or your .NET application packages to the Azure administration portal, or directly from Visual Studio. You let Azure automation configure the VMs and distribute your content to them behind the scenes.

Azure Compute Instance: The disposable VM

If what you want to do in Azure Compute is beyond the scope of the Web or Worker roles, Microsoft gives you complete access to the VM instances themselves -- the VM role. In this role Microsoft does not have an SLA on the OS of the VM because you upload your own VM virtual hard drive (VHD) image and Microsoft does not perform any updating on the OS.

The Azure VM role is not like other conventional hosted VM environments. The biggest difference is that you can only deploy VMs in pairs and get coverage by the Windows Azure Compute SLA from Microsoft. If you deploy a pair of redundant VM instances as part of one Azure VM role, there is a 99.95% SLA on the availability of the role.

Instead of striving for extreme high availability on individual servers, Microsoft takes a different approach to risk management in the Azure platform. VM failure is allowed and expected and planned for, either in the application layer or a contingency workflow process. (For the Azure software architect, there are some ways to provide persistent storage to Azure VMs.)

If an Azure host has a hardware failure, one VM instance will be lost. You will permanently lose any unique data that was on the system VHD or in the memory of that VM instance. Azure will respond to the failure by spinning up a new VM to replace the lost VM, but using a generic"sysprep'ed" Virtual Hard Drive (VHD) image you have uploaded. Meantime, it is assumed your overall application continues to run okay using the surviving VM instance(s) in that role.

  • In the case of the Web and Worker roles, since IIS and .NET applications generally work well behind load balancers, the loss of a particular IIS server in a web farm does not stop the web application as a whole. This model for Web and Worker roles is how Microsoft offers an SLA on the availability of the platform-they just need to keep sufficient VM instances of a Web or Worker role running to meet the SLA.
  • In the case of the VM role, the overall enterprise distributed application (that your VM instances are part of) has to be architected to allow for the non-persistence of particular Azure VM instances. Most infrastructure roles won't fit this model without modification.
  • If your VM role application can't run (as native Azure VMs do) with a random computer name and in a default "workgroup" configuration without any configuration, consider either (1) authoring an automatic provisioning routine that pulls or pushes configuration to the VMs after they are deployed, or (2) performing a manual step, such as using remote desktop protocol (RDP) to manage new VM instances and configure software installed in the image.

Pricing, Windows license, and trial information

The pricing model for the Windows Azure VM role is the same as that for the Web and Worker roles. Customers are charged depending on the compute instance size. The Windows Azure fee for running the VM role includes the Windows Server licensing costs. Additionally, there is no requirement for Windows Server Client Access Licenses (CALs) to connect to the Windows Azure VM role.

Getting starting with Azure is made easier by Microsoft offering a number of low-cost or even free trial subscriptions to Azure.