The difference between Azure VMs and Azure VM Role

All compute resources in Windows Azure run on virtual machines, but not all virtual machines are the same.

VM Role

You send your own OS image, along with any attendant software, service packs, patches, updates and applications already installed, to Windows Azure. Let’s call that image the “golden image”. You are responsible not only for the application, but also the health of the underlying operating system: you must patch and maintain it. You can apply updates through differencing disks, so you don’t have to re-submit 20-30 GB system images each time. Effectively the original image, plus the differencing disks becomes the new golden image.

There are many reasons the fabric might decide to start your VM Role on a different host (like a persistent blue-screen maybe). To do this, it acquires the golden image, finds a new host and fires up the image. When this happens, it abandons the old VM and marks the slot on that host as “available”, for a different customer. Hence, any changes you make, say to the local file system, will be lost.

IaaS Virtual Machines

The preview of Virtual Machines, announced on the 6th and 7th June (see the video here), are literally VMs as you understand them from the on-premises world, running in the Windows Azure data-centers. You are still responsible for patching and maintaining the OS and everything that runs above it, but, these systems are fully durable across planned and unplanned reboots. If you make a change to the registry or the file system or if you say, register a COM component, even if the system fails and the fabric moves the workload to a different host in an entirely different part of the Windows Azure data-center, the change will survive the move and the reboot. It will behave just like a VM in your own on-premises environment. All the changes you made will still be there after the move.

 

But why?

If you are new to Windows Azure, it’d be entirely reasonable to ask “why would anybody want a VM that doesn’t guarantee to save its data across a reboot?”. For this, you need to get your head up out of the instrument panel and the cockpit and take a broader view. These previews introduce Infrastructure as a Service (IaaS) capabilities to Windows Azure. It has, until now, been a Platform as a Service (PaaS) offering. PaaS says “send me the code and I will run it for you”. To this end, Windows Azure Cloud Services (as they are now called) introduces three roles:

1. Worker Role
2. Web Role
3. VM Role

Worker Roles are designed for fast provisioning and de-provisioning of your cloud applications. You specify you want one or more of these VMs by using the service management API. One of the most common ways of calling this is to provide a service model with an <Instances count="n" /> field. This will scale your application out, or back and take care of pretty much everything for you. It will:

1. Acquire a robust and correctly patched operating system image: one that was created, patched and maintained by Microsoft.
2. Identify a host machine to run it on. This host will be in a different rack, connected to a different router, different load-balancer, different power supply and so on, to other VMs within that role you have created.
3. Copy the VM to the host and boot it.
4. Create separate subnets for each role and be connected to a router that will only route traffic to/from the VMs in your Azure application, and only on the ports you specify in your service model.
5. Each external port (again, specified in the service model) will be connected to the load balancer and firewall and eventually to the Internet.
6. Be given an external virtual IP address and DNS name.
7. Run any startup tasks you specify in your service model. For example you might install specific runtime environments or API families that your code will call.
8. Hunt around inside the application package you sent and get the right code on to the VM
9. Start your code.

This is all done automatically. You will find you can provision most applications, even ones with complicated multi-tier architectures and multiple servers, in between 8 and 15 minutes.

 

The screenshot (in the old portal) above shows a Windows Azure application with 20 VMs deployed: 6 Web Role Instances (Web Front End) and 14 Worker Role Instances (CRM Processing, App Reporting, CRM Reporting, Monitoring and Policy Module). It took 15 minutes to deploy this application and get it to a state where it was live and running on the Internet.

Web Roles are the same as worker roles except that in among all those steps (1-9 above), it will startup and configure IIS.

Because by the time a startup task runs, the operating system is booted (it has to be to run your startup task), your startup task can be as complicated and time-consuming as you like. That’s where the problem lies and that’s where VM Role comes in. Let’s imagine your startup task does a scripted install of an application and it takes on average 45 minutes to complete. If you add that to the default boot time of maybe 15 minutes, it’s going to take 60 minutes each time you provision a VM in such a way.

By having a VM where the work of installing the code, setup, runtimes etc has been embedded in to the golden image, it will only take say 15 minutes to boot the VM. It comes with the disadvantage of having to maintain the OS yourself – patch it, apply security fixes and service packs etc, but you get the advantage of fast-provisioning. This means you can now respond to an increase in demand in a few minutes rather than an hour or more.

The next question you might reasonably ask is “why even bother with VM Role. Surely an IaaS VM is a better bet – I have to maintain the OS anyway”. It’s true, there is a degree of merit in this sentiment. But the IaaS environment means you have to also work with the infrastructure. This means you have to, for example, set the load-balancing between VMs up. You can’t just simply edit a line in your service model, a la “<Instances count="4" />” and have all the operations associated with automating the entire provisioning process kick-off and then 15 minutes later, after you’ve finished your coffee, be enjoying the additional capacity.

Advantages/dis-advantages

ALthough IaaS VMs and VM Role appear similar, they are different. One is durable (IaaS VMs), the other is not (VM Role). One benefits from fast provisioning/de-provisioning as part of the service model (VM Role), the other doesn’t (IaaS VMs). Of course the big benefit of IaaS VMs is that you can take just about any on-premises application, whether it makes changes to the local file system or not (even if the OS is one of the supported Linux distributions) and deploy it to the cloud for a few cents per hour.

Is it just hosting?

With a hoster, you can’t provision a VM, either PaaS or IaaS, in such a short time. You can’t get all the infrastructure for a complicated app set up and provisioned in such a short time. The commercial model of most hosters is to charge you for a VM and offer a sliding scale of charges depending on the length of the contract. A 2-year contract gives a lower monthly fee than a 6 month contract. You pay for the VM whether you are running it or not. One thing you can’t do with a hoster is pay for one hour of VM usage. With a cloud environment you can literally provision a VM with your app for one hour and then de-provision. It will cost you 2 cents to do that (or nothing if you use a free 90 day trial account) on an extra-small instance (1.0 GHz single core, 768MB RAM).

Comments

• Anonymous
  June 07, 2012
  Great article and very easy to understand.  Thanks for sharing.

• Anonymous
  December 11, 2012
  GOOD

• Anonymous
  January 23, 2013
  Very Good, easy to understand.

• Anonymous
  May 23, 2014
  This article is valuable, but I wonder if it might be a little out of date.  In the two years since this was written, how has Azure's terminology / offerings changed?

• Anonymous
  July 12, 2015
  ...well, I think that's part of the problem. The official terminology hasn't changed. An Azure VM, is a stateful VM out of the IaaS offering, just like it was on 22nf June 2012 when it was released. No change there. VMRole no longer exists, but when referring to that name we should be referring to the stateless VM as described. The trouble comes with people who wrongly describe an Azure VM as a VMRole. It's either an Azure VM. OR an Azure VM Role. The 2 terms are not interchangeable and Microsoft hasn't tried in any way to re-purpose the terminology. Hope that helps.

• Anonymous
  January 27, 2016
  With one of these options is it possible to deploy a work role inside an azure virtual machine?