Why does Azure need a VM role now Hyper-V cloud is here?
Cloud and virtualisation are related ideas, but they're not the same thing. To Microsoft the real benefit of its Azure cloud service is more than elasticity and scaling and economies of scale; it's that you can have Windows servers without having to do the work of running Windows Server yourself. At PDC, Bob Muglia called 'platform as a service' the 'true north' for Microsoft - but then he announced that you'll be able to upload and run VMs of your existing apps in the cloud, which sounds like the much more common 'infrastructure as a service' cloud offering, or the kind of thing you'd want to do on a Hyper-V Cloud system. Is Azure being a bit schizophrenic?
"The reason that Platform as a service is the north star for us," senior product manager Aashish Dhamdhere explained to us last week, "is that's the model that delivers the most benefits for the cloud to developers and businesses." Developers get to focus on their app and on writing code and not on worrying about deployment; we've often described developers handing over a project to the IT department as throwing code over the wall. "But now that IT team is Microsoft," agrees Dhamdhere "and if you want 50 instances of your app you can get them in 15 minutes". In the old days, it would have taken Bing six months to roll out the number of services they needed for the recent Twitter integration; plenty of time for a more agile search engine to get to market first.
So why is the VM role not a step backwards? "If you truly believe PaaS is what makes the cloud most viable you have to write apps in a particular way that makes them scalable, so you can add hundreds or thousands of instances as demand dictates," points out Dhamdhere. "You don't want hardware failure to get in the way of serving your customer - and this is all commodity hardware so it's a question of when not if. We've written that platform so that you're completely shielded - as long as you write your app following the programming model and have at least two instances. Any time you upload a workload to Azure we replicate it three times and we put it in three different fault domains… You can write new apps using this model that will give you all these benefits, but what about my existing apps? What about all the apps sitting in my data centre today that I want to move to the cloud? The VM role gives you bridge to take apps and make them fit the model; it's still a stateless implementation that fits the Azure model - but it's my existing app."
You do get load balancing, and as long as you run two instances of the app you get fault tolerance (though if one instance goes down you won't get the data state back from it). And of course you have to manage the VM… but unlike Hyper-V Cloud, at least you're not managing the whole private cloud.
Yes, it's a stopgap. For some companies that will be the first step in rewriting their app fully; for others, it's a way to take legacy code to the cloud and there are companies that need that says Dhamdhere. "Suppose I have a media transcoding solution written by somebody in the company who left a long time ago and don’t want to mess with it - but I do want to run it in the cloud."
Why not just use application virtualisation and run that on Azure? If you can, you should, he says; if you only need to make small changes to an app that you don't want to be permanent you can use the elevated privileges now available for the other Azure roles. But if you have an app with a long setup and a customised install, the VM role is a better fit.
Mary Branscombe