Back in October of 2010 Microsoft announced the new Virtual Machine (VM) role for its Windows Azure Platform at PDC. As opposed to the Web (link) and Worker (link) roles, the VM role allows you to define the configuration of the operating system you deploy in the Azure environment (with some limitations). You can also control (and are actually responsible for) updates to the operating system. For an overview of the VM role I recommend you read this article on MSDN.
Numerous people in the industry heralded this move as Microsoft’s entry into the Infrastructure as a Service (IaaS) space. I, on the other hand, cringed. There are two specific issues I have with the VM role as it exists today. The first is an issue of perception. As I’ve mentioned in other posts I’ve spent the first half of this year helping Microsoft deliver Windows Azure Boot Camps in the central region. During the third module of these events I talk about advanced roles in Windows Azure, and one of the roles I discuss, as you can probably guess, is the VM role. If people aren’t familiar with the Platform as a Service (PaaS) model, they can have a hard time understanding the execution environment of a Web or Worker role. However when I bring up VM role the eyes of the attendees light up. They know what VM’s are, they use them all the time. All of a sudden, they think it just got a whole lot easier to uplift their on-premises installations to Azure. I then get bombarded with questions, lots of questions. Below are just a sampling of questions I’ve received during these sessions:
- “Can I overcome the current SQL Azure size limitations by deploying SQL Server in a VM role?”
- “Can I deploy a domain controller to Azure using the VM role?”
- “Can I deploy a SharePoint farm using the VM role?”
- “Can I deploy Dynamics using the VM role?”
What I don’t like about these questions is that I have to answer “Yes, it is technically feasible to deploy [insert technology] with the VM role.” However, I’m usually quick to follow that response with,”…but just because it is technically feasible doesn’t mean you should.” Let’s use SQL Server as an example. If I created a VM with SQL installed I could probably get it running in Azure. My applications could then leverage this database to store more than 50 GB of data. But, what if the rack where my VM running SQL goes down? Well the Azure fabric controller, will take the base VM image with SQL installed and spin up a new instance. Which is great. Except all the data that was on my other VM is gone. You know, that 50+ GB of data. This is because Azure is a stateless environment. If you want your custom built VM’s to run in Azure they need to be stateless as well, which rules out a number of scenarios.
Another train of thought is that VM role is intended for legacy applications. I can understand how one could arrive at this conclusion. There is one slight complication. Typically legacy applications don’t run on the latest operating system, hence the term legacy. As of this post, the Windows Azure VM role requires that the VM you build be Windows Server 2008 R2 Enterprise Edition, not exactly your legacy OS. So, if you had grand visions of creating a Windows Server 2003 VM for your application that is dependent on that particular flavor of OS so you could move them to Azure, and yes those apps do exist, it isn’t going to happen. At PDC Microsoft mentioned that they were *looking* at providing support in the VM role for Windows Server 2003 and later, but no official roadmap has been announced.
You’re probably thinking to yourself, “Enough already! So, when should I use the VM role?” Well if you read this MSDN article, you’ll see that Microsoft gives three scenarios as valid uses of the role. I’ll take them on one at a time.
Long running setup – If you are creating an application that requires a long running setup, you may want to use a VM role to do this processing.
Maybe your application does take a long time to get up and running, some apps do. What you have to ask yourself is this, “Is it really worth the additional work required (i.e. patching the OS, deploying updated VM’s,etc.)?” I would argue that in most cases it isn’t. While the VM role isn’t IaaS it is not entirely PaaS, as you are taking on a number of responsibilities that, in a true PaaS model, should fall to the vendor.
Error prone installations – If your application has a higher percentage of possible installation problems, you can make sure that the installation finishes successfully before you deploy the image to Windows Azure.
Wow! Really?! Is this suggesting that you mask the fact that your application has significant install issues by throwing it in a VM? I’m speechless. This doesn’t pass my smell test for solid guidance. Maybe, just maybe, you should look at fixing your problematic installation. Of course, that’s just my opinion.
.
Manual interaction in the installation – You must use a VM role if your application requires any type of manual interaction in the installation.
Hmmm. This one I just don’t get. With the introduction of admin rights and startup tasks in version 1.3 of the Azure SDK, I’m wondering if this scenario is actually valid where people think it may apply.
I know you’re probably screaming at your screen by now, “But tell me WHEN to use the VM role!” (Either that or you stopped reading this post altogether.) I honestly wish I could, but the truth is I don’t know. In my opinion, until more guidance is provided and the concerns I raised above have been addressed, it should be avoided altogether.
(Glad I got that off of my chest.)
Additional Resources