Once, long ago, men carved their knowledge into the walls of caves so that it would be available for all time. Unfortunately, their knowledge was tied to once place. Eventually, a forward thinking cave dweller thought about carving his knowledge into a clay tablet. He was savagely beaten to death and his family burned as witches. Eventually the other cave dwellers realized that it was probably a good idea to have a more portable way to store their knowledge and they too adopted this portable clay-based knowledge transfer system.
Fast forward to the tail end of 2010 and people are saying that Microsoft has got it wrong with the Azure VM role. People are already lambasting it as a laughable concept that’s needlessly complex to patch. I can’t argue with that, it is complex to patch, but there’s a reason for that complexity and it’s called stateless computing.
It’s like the switch from procedural/object-oriented programming to functional programming. When you first switch, you get pissed off that you can’t reassign variables and that functions can’t have side effects. You get used to that pretty quickly and start doing crazy things with tail recursion and other functional paradigms that ultimately save you memory. remove debugging headaches, and give you an incredible amount of computing stability.
With the last paragraph in mind, let’s look at Azure VMs again – we can’t patch the VM directly. It’s stateless. What does a stateless VM buy you?
- It’s easy to spin up additional, identical VMs. There’s no worrying if some master image is the same: it is.
- It’s easy to back out incompatible patches – just remove the differencing VHD.
- There are no side effects because of errant garbage living on the C: drive.
- Security – if a virus infects your VM, just reboot.
- Complex, time consuming patches can be applied once and quickly moved into place.
- There’s a load balancer in front of every Azure instance. Operations must be idempotent, even when executed against different instances.
Managing state isn’t a component of your operating system in Azure, it’s a component of the storage tier. New paradigms require new ways of thinking. Sometimes a new way of thinking seems broken, wrong, or foolish.
If you’re looking to customize your Azure deployment stack without sacrificing the flexibility of using Azure, then Azure VM roles are for you.
If you’re looking for a replacement for your current VM Ware installation, Microsoft’s Azure VM roles aren’t for you. But while you’re fiddling around with VM settings, I’m going to be playing Scrabble.
Comments
HAHAHA, dude, c’mon, let’s break this down.
“Security – if a virus infects your VM, just reboot.” – OK, so how are you going to detect viruses? Remember, antivirus software updates the OS drives and registry, and every time a new definition comes out, that’s saved on the OS drive. Whoops…
“Complex, time consuming patches can be applied once and quickly moved into place.” – WHAT? Do you even understand how Azure VM patches work? You have to apply them locally in YOUR datacenter, then create a differencing VHD, then upload that to the cloud, then reboot all your instances. How the hell is that even remotely quick?
Truthfully, if a virus even gets on an Azure VM, we’ve all probably got bigger things to worry about, but you have a point – there needs to be a different way to monitor for viruses.
And yes, I do understand how the patching process works. I agree, it’s not perfect, but I also think that my argument has merit. Take the upgrade process from TFS 2005 to 2008 – it clocks in at around 50 or 60 steps. If I have to repeat a similar process on 20 servers, that’s a lot of time I could spend doing something else. If I can instead do the same thing on one server and push it up, then it’s a step in the right direction.
Ultimately, state doesn’t belong on a server, state belongs in a storage mechanism. The core operating system has no business doing anything other than handing off requests to storage subsystems. Aren’t we all not supposed to be putting anything on our C: drives anyway?
About monitoring – as long as you’re talking monitoring for viruses, think about *any* monitoring. You do wanna use a monitoring tool, right? Most of ‘em change the OS drive, and many even require a reboot. Whoops.
About patching – dude, c’mon, saying Azure VM role updates aren’t perfect is like saying the Ford Pinto wasn’t perfect. Wait until they get it right before you plunge into this redonkulous update scheme, go easy on the DAC deployments, and hold off on taking rides in the Pinto. You wanna make sure the vendor will actually *fix* what’s horrendously broken before you make an infrastructure investment in a proprietary system like Azure, because you need to make damn sure v2.0 will come out. Microsoft doesn’t exactly have a good reputation for continuing investments in existing features.
The AV problem has a solution we came up with years ago… It’s scanning from a different system. If you’re talking about something running in memory, then we’re looking at IDS/IPS, which we should have already in this day and age (especially since Snort is free).