Share via

If VM Role isn’t IaaS, where exactly, does it fit in?

  • Article

Amazon, traditionally an IaaS cloud provider, has now introduced Beanstalk, a PaaS model for the cloud.  Their IaaS model has served them well: you provide a VM, they run it for you. To round out the model they provide additional services such as storage and database. This model has made Amazon by far and away the most successful cloud operator in the market, as we speak, in terms of the volume of compute they run. So, with such a successful model, that has brought them large market share, why are they introducing a PaaS model?

I believe it’s because to truly take advantage, customers will start to demand more PaaS-like services as cloud technologies mature. The IaaS model is so easy to migrate to the cloud because, in no small measure, you replicate what you have in your data-centre, save for those additional services I talked about, like storage (which you don’ t have to use).

This means, you replicate all the problems of running applications in your data-centre as well. That’s not to say there is no place for IaaS – there absolutely is. IaaS offers the pay-as-you-go and only-pay-for-what-you-use model that the data-centre, in most cases, can’t match. It also increases business agility. You could go from making the decision to put an application in the IaaS cloud, to actually running it in the cloud, in less than a day. In fact, in less than an hour if you want to throw caution to the wind. So, with IaaS, the transition-time from deciding to move (or create in the first place) an application to the cloud, to actually doing it, is very short indeed.

Not so with PaaS applications. The reason, is that PaaS applications have to be written with the PaaS platform in mind. You only concentrate on the business logic. The management, monitoring and provisioning is automatically handled by the platform. The application lifecycle is taken care of for you by the cloud operator. As a developer, you are granted a shared pool of compute, storage and network resources and you don’t have to manage any of that. As a developer you can concentrate on being a developer. Remember, managing applications is something you are forced to do. It’s not something that has intrinsic value to the organisation.Microsoft’s Mark Russinovich says “treat the data-centre as if it’s the machine”. You end up with the resources of the entire data-centre curling around your application.

OK – so where does that leave VM Role. I’ve heard, many times “VM Role is the way Azure does IaaS”. I’ve even heard this from Microsoft commentators – who I believe were trying to simplify a message in to a small, easily digestible chunk – but they actually got it wrong.

In a couple of previous posts, I’ve talked about why it is that VM Role is not IaaS and why, for example you definitely wouldn’t want to use VM Role for say, a Domain Controller. In this post, rather than saying what VM Role is not. I’d like to concentrate on what it is. Where it does fit in to the PaaS model.

Windows Azure is about building applications

When you build a Windows Azure application, you don’t think about the operating system. Sure you think about APIs and so on, but the operating system itself is handled by the platform. When you make updates to your application, the operating system and local storage are left untouched. It’s the same when you make configuration changes to your application – the operating system and local storage remain untouched. The notion of configuration-drift disappears. You update the application and your configuration changes flow, automatically. When you need to scale out – this is handled in a known, controlled and consistent way. Scaling is achieved through multiple instances of the application, so sure, you have to write your application in a very specific way, to allow for this. But the scale out is achieved because instance management creates identical instances. Availability comes because of the ways failure management is done – automatically, meaning you don’t suffer when hardware fails or the operating system on one of your instances crashes. You also get automated, consistent servicing of the operating system. This is achieved through image based OS patching. Security patches are applied in a known, controlled and consistent way across all your instances, with availability not having to suffer while this is done.

What I tried to do in the previous paragraph is highlight how consistently the OS is managed, such that you never have to worry about the OS. Windows Azure is a platform that has successfully managed to separate the OS from the application. But if VM Role gives you access to the underlying operating system, where on earth does it fit in to this picture if Microsoft is still saying that VM Role is a PaaS offering. The way to think of it is like this:

  1. A Web Role is a website hosted on IIS.
  2. A Worker Role is an application hosted on Microsoft’s Windows image.
  3. A VM Role is your pre-loaded application hosted on your Windows image.

image

You can see there is a continuum between abstraction and control. In those situations where you don’t feel you have enough control, you are forced to move away from abstraction. With VM Role, you get another module bolted on to the end of the control extreme of the continuum:

image

So, there are a few specific ideal-use-cases for VM Role. The first one is where the application install is lengthy. Sure, you could do it with Startup Tasks in a Worker Role, but think what that does for the responsiveness when you want to say scale out. I find that most deployments take about 10 minutes to get to a Ready state. If you add 30 minutes on to that because of a lengthy installation that has to happen during a Startup Task, it means you also need to add 30 minutes on to the time it will take you application to scale-out when you increase the instance count. If the application is already installed in to the image you supplied (see bullet #3 above), you don’t have to suffer that time-delay. The next one is error-prone application installations: the sort of things a human being can react to and make the right decisions, but which a Startup Task would struggle with. Even with a 1% or 2% failure rate on application installations, in a large deployment that can add up to a lot of instances. The third one is any application that requires a manual-installation: clicking buttons, typing in to text boxes etc.

I talked briefly about consistency above and believe it or not, VM Role benefits from all but one of the things I talked about in that paragraph. Let me just repeat that paragraph here, highlighting the only differences in red:

 

With VM Role, the notion of configuration-drift disappears. You update the application and your configuration changes flow, automatically. When you need to scale out – this is handled in a known, controlled and consistent way. Scaling is achieved through multiple instances of the application, so sure, you have to write your application in a very specific way, to allow for this. But the scale out is achieved because instance management creates identical instances. Availability comes because of the ways failure management is done – automatically, meaning you don’t suffer when hardware fails or the operating system on one of your instances crashes. However, you don’t get automated, consistent servicing of the operating system. You must patch the OS yourself. It’s the same with security patches and hotfixes. Again though, when you look at what you do get, a great deal of it is the same. I previously said, in a different post, that the best way to think of VM Role is that instead of supplying just the .cspkg (plus service model) to Microsoft to run (as in Web and Worker Role), you supply a .vhd. When you think of patching your application, you should consider the entire .vhd a bit like a .cspkg. If there’s something wrong with it, including the underlying OS, then you patch it. VM Role gives you an efficient way of doing this with differencing files, so you don’t have to redeploy an entire multi-gigabyte .vhd for say one patch.

There is a quid-pro-quo transaction for all the benefits of service management you still get from VM Role though. The deal is that you must write your application with 2 core architectural principles embedded throughout. The application should be stateless and the application should be capable of running on multiple instances. By being stateless, you still get the benefit of consistent updates, consistent configuration and multi-instance updates. By being capable of running on multiple instances, you still get the benefit of scale-out and high-availability. Now, this obviously means that not all applications are good candidates for being moved to VM Role.

Summary

VM Role is not an IaaS solution. It extends the limit of the abstraction-control continuum further in the direction of control than abstraction, but there is still significant abstraction. This means VM Role still benefits from the Windows Azure service model. So for example the idea of configuration-drift disappears, configuration changes automatically flow, code changes automatically flow etc. However, the deal is that you must create applications around a multi-instance, stateless architecture and you don’t get the benefits of automated OS service management. You must become the manager of the OS. However, you only do that for your “golden image” – once deployed, it flows, automatically, just like the application you installed on to it does. VM Role is particularly suited to multi-instance, stateless applications that have these properties: they have long or error-prone installation procedures or they have manual installation requirements. The way to think of VM Role is like this:

  1. A Web Role is a website hosted on IIS.
  2. A Worker Role is an application hosted on Microsoft’s Windows image.
  3. A VM Role is your pre-loaded application hosted on your Windows image.

 

Planky – GBR-257

Comments

  • Anonymous
    March 18, 2011
    Planky, I would be interested to hear any specific use case where you would recommend a VMRole as the desired implementation.  Also, what is the expected time frame for spinning up a new instance of a VM role? You still have to copy the VM image from cache (blob storage?) to the newly created VM.   -Mike

  • Anonymous
    March 20, 2011
    Michael, I've just posted a new blog post on this matter. (cloudythoughts.siadis.com/.../when-to-deploy-a-vm-role-in-windows-azure) It's the actual installation time of the software installed on a VM Role that is saved. Not the amount of time copying the installation files. If you trigger the installation with a startup task in, for instance, a worker role, you still have to wait until the installation is done. So, when the installation process of your software takes a long time, you should consider the VM Role. Otherwise, use a worker role and start your applications with a startup task. With kind regards, Patriek van Dorp http://www.patriekvandorp.net

  • Anonymous
    October 24, 2011
    There are some problems to update VM ROLE in Azure:

  1. To add a SSL certificate after deployment, it nearly impoosible if you did not plan ahead, because you need using differencing .VHD to do that, but that brings on second problem.
  2. VM Role image been sysprep-ed before upload. So to add a differencing .VHD, you need run the base image on local VM, but that requires you boot into base image, thus un-sysprep-ed the image. A Windows image can only be sysprep-ed a few times(3?), after that it will no longer works. So currently AZURE VM Role is not very useful for most deployments.