Incomplete Thought: Virtual Machines Are the Problem, Not the Solution…
I’m an infrastructure guy. A couple of days ago I had a lightbulb go on. If you’re an Apps person, you’ve likely already had your share of illumination. I’ve just never thought about things from this perspective. Please don’t think any less of me
You can bet I’m talking above my pay grade here, but bear with my ramblings for a minute and help me work through this (Update: I’m very happy to see that Surendra Reddy [@sureddy - follow him] did just that with his excellent post – cross-posted in the comments below, here. Also, check out Simon Crosby’s (Citrix CTO) post “Wither the venerable OS“)
It comes down to this:
Virtual machines (VMs) represent the symptoms of a set of legacy problems packaged up to provide a placebo effect as an answer that in some cases we have, until lately, appeared disinclined and not technologically empowered to solve.
If I had a wish, it would be that VM’s end up being the short-term gap-filler they deserve to be and ultimately become a legacy technology so we can solve some of our real architectural issues the way they ought to be solved.
That said, please don’t get me wrong, VMs have allowed us to take the first steps toward defining, compartmentalizing, and isolating some pretty nasty problems anchored on the sins of our fathers, but they don’t do a damned thing to fix them.
VMs have certainly allowed us to (literally) “think outside the box” about how we characterize “workloads” and have enabled us to begin talking about how we make them somewhat mobile, portable, interoperable, easy to describe, inventory and in some cases more secure. Cool.
There’s still a pile of crap inside ‘em.
What do I mean?
There’s a bloated, parasitic resource-gobbling cancer inside every VM. For the most part, it’s the real reason we even have mass market virtualization today.
It’s called the operating system:
If we didn’t have resource-inefficient operating systems, handicapped applications that were incestuously hooked to them, and tons of legacy networking stuff to deal with that unholy affinity, imagine the fun we could have. Imagine how agile and flexible we could become.
But wait, isn’t server virtualization the answer to that?
Not really. Server virtualization like that pictured in the diagram above is just the first stake we’re going to drive into the heart of the frankenmonster that is the OS. The OS is like Cousin Eddie and his RV.
The approach we’ve taken today is that the VMM/Hypervisor abstracts the hardware from the OS. The applications are still stuck on top of operating systems that don’t provide much in the way of any benefit given the emergence of development frameworks/languages such as J2EE, PHP, Ruby, .NET, etc. that were built around the notions of decoupled, distributed and mashable application “fabrics.”
Every ship travels with an anchor, in the case of the VM it’s the OS.
Imagine if these applications didn’t have to worry about the resource-hogging, control-freak, I/O limiting, protected mode schizophrenia and de-privileged ring spoofing of hypervisors associated with trying not conflict with or offend the OS’s sacred relationship with the hardware beneath it.
Imagine if these application constructs were instead distributed programmatically, could intercommunicate using secure protocols and didn’t have to deal with legacy problems. Imagine if the VMM/Hypervisor really was there to enable scale, isolation, security, and management. We’d be getting rid of an entire layer.
If that crap in the middle of the sandwich makes for inefficiency, insecurity and added cost in virtualized enterprises, imagine what it does at the Infrastructure as a Service (IaaS) layer in Cloud deployments where VMs — in whatever form — are the basis for the operational models. We have these fat packaged VMs with OS overhead and attack surfaces that really don’t need to be there.
For example, most of the pre-packaged AMIs found on AWS are bloated general purpose operating systems with some hardening applied (if at all) but there’s just all that code… sitting there…doing nothing except taking up storage, memory and compute resources.
Why do we need this? Why don’t we at at least see more of a push towards JEOS (Just Enough OS) in the meantime?
I think most virtualization vendors today who are moving their virtualization offerings to adapt to Cloud, are asking themselves the same questions and answering them by realizing that the real win in the long term — once enterprises are done with consolidation and virtualization and hit the next “enterprise application modernization” cycle — will be to develop and engineer applications directly around platforms which obviate the OS.
So these virtualization players are making acquisitions to prepare them for this next wave — the real emergence of Platform as a Service (PaaS.)
Some like Microsoft with Azure are simply starting there. Even SaaS vendors have gone down-stack and provided PaaS offerings to further allow for connectivity, integration and security in the place they think it belongs.
In the case of VMware and their acquisition of SpringSource, that piece of bloat in the middle can be seen as simply going away; whatever you call it, it’s about disintermediating the OS completely and it seems to me that the entire notion of vApps addresses this very thing. I’m sure there are a ton of other offerings that I simply didn’t get before that are going to make me go “AHA!” now.
I’m not sure organizationally or operationally that most enterprises can get their arms around what it means to not have that OS layer in the middle in the short term, but this new platform-oriented Cloud is really interesting. It makes those folks who may have made the conversion from server-hugger to VM-hugger and think they were done adapting, quite uncomfortable.
It makes me uncomfortable…and giddy.
All the things I know and understand about how things at the Infrastructure layer s interacts with applications and workloads at the Infostructure layer will drastically change. The security models will change. The solutions will change. Even the notion of vMotion — moving VM’s around — will change. In fact, in this model, vMotion isn’t really relevant.
Admittedly, I’ve had to call into question over the last few days just how relevant the notion of “Infrastructure 2.0″ is within this model — at least how it’s described today.
Cloud v1.0 with all it’s froth and hype is going to be nothing compared to Cloud 2.0 — the revenge of SOA, web services, BPM, enterprise architecture and the developer. Luckily for the sake of us infrastructure folks we still have time to catch up and see the light as the VMM buys us visibility and a management plane. However, the protocols and models for how applications interact with the network are sure going to change and accelerate due to Cloud — at least they should.
Just look at how developments such as XMPP and LISP are going to play in a PaaS-centric world…
Like I said, it’s an incomplete thought and I’m not enlightened enough to frame a better discussion in written form, but I can’t wait until the next Infrastructure 2.0 Working Group to bring this up.
I have an appreciation for such a bigger piece of the conversation now. I just need to get more edumacated.
My head ahsplodes.
Any of this crap make sense to you?