Windows Azure is a Platform-as-a-Service offering. Many people have already recognized the power and synergetic opportunity behind this approach to offering a cloud platform. Living at the abstraction layer above infrastructural offerings, Azure is pretty different from IaaS offerings. It’s primary focus is: enabling developers to build applications like MySpace, eBay, ciao.com or facebook without – and that’s the important part – having to worry about or deal with infrastructure.
That way, every piece of web you put on Windows Azure is automatically loadbalanced. That’s a hell of a feature, really ! Also, that makes you implicitly scalable, if you managed to make your app stateless. It’s really amazing, what the platform does for you. Really really amazing. There’s tons of more features and we’re discussing all of them in detail in posts, articles, videos. So I don’t want to dive into a platform overview here.
One of the ideas behind the Azure platform, people usually don’t like, is the loss of direct control. You upload your packetized social network frontend and services to the platform and that’s it. No ability to configure IP-Adresses or do RemoteDesktop sessions and so on. All of that is simply explained: you don’t need to have that sort of access and you don’t really want it. Azure will take care of all of that. Theoretically.
Practically there have been things this paradigm could not fully answer. For instance, if you need to bring preinstalled “machines” from you virtualization grid to the cloud. Or when you need a part of monolithic legacy with your .NET 4 MVC 3 Webapp that manually dials and sends faxes. In such cases, the easiest way to think about it is: let’s put a Virtual Machine on Amazon’s EC2.
Now, EC2 is an IaaS offering. It is very good, innovative in it’s scope and you almost never hear a bad word from a customer. So this sounds like a pretty good idea. Besides, you can control everything from the IP to the restart schedule. And it this case, you can accept the tradeoff, that you will have to care about the infrastructure, the updates, patches along with a well crafted how-to-scale-this idea.
With the arrival of the WindowsAzure VMRole, many people start to think of it as probably being ”just like other VMs in the cloud”. Yes… and that is where it happens.
Azure VMRole is NOT like other VMs in the cloud and it won’t be for a long time. Azure VMs are a hybrid approach that from my perspective are neither VMs nor platform roles. And when using them – which you can easily start by doing little more than uploading a WindowsServer 2008 R2 Hypervisor VM – you need to understand some very basic exceptions to the “VMs in the cloud” manifesto.
- Azure VMs don’t have static IPs
- In fact, the IP changes with each redeployment or even more regular
- Azure VMs don’t live forever
- You need two of them to make it into a high availability scenario
- If you have more than one machine in your subscription, they share the IP address
- You have very limited and complex ways of talking to exactly one of the machines
- That makes you want to have VMs that “pick” jobs from a queue instead of waiting for them to be pushed
- The fabric controller will give you a new VM, if one of your existing instances crash, but it will start with the naked image you provided. So probably you don’t want to hold your produced data in the VM and put it on AzureDrives or manually feed the Blobs.
Do we recommend the usage of Azure VMRoles ?
Only after a thorough architectural design assessment and only after evaluating the less “hybrid” alternatives, preferably the PaaS paradigm. If you can, go there.
Any questions ?
Put them in the boxes below
Cheers,
Markus