The Frankencloud

calendar Mar 6, 2012 · 6 min read  ·
Share on: linkedin copy

For a change, last week on twitter there was a discussion about multi hypervisor deployments. Knowing that, after food and family, multihypervisor is my biggest interest, I was taken and thrown into that discussion. Again. Unfortunately.

Yes, I do have (strong) opinions about the thing but, regardless, I believe it will happen anyway. Read on.

The best way to clarify my position is to distinguish between use cases and scenarios: the typical Private and Public cloud implementations.

Private Cloud Implementations

Let me quote a few customers I have met lately (all true stories, I swear).

  • "I will deploy Hyper-V because I was told Microsoft SQL runs faster"

  • "I am deploying XenServer because I am using Citrix XenDesktop and I feel more comfortable with an end-to-end stack"

  • "I need KVM because I am moving a 32-way Unix partition running SAP and vSphere 4.1 doesn't support that many" (note: 5.0 does but they haven't upgraded yet)

  • "I need to deploy OracleVM because Oracle won't support their software on VMware vSphere"

  • "We don't go to central IT, we have our own farm and we have chosen to use a different hypervisor"

  • "My strategy is to create different hardware and software silos (this includes hypervisors) for extreme tuning and vertical optimization" (by the way: this reminded me of my AS/400 days).

  • "I want to use another hypervisor so that I can put more pressure on VMware at the next ELA renewal"

We can stay here days discussing these things. Except the last one. He was the most candid of all, the least convoluted and, frankly, the only one that REALLY got it. And because he gets it, it doesn't mean that he's going to split evenly his production workloads between two hypervisors if you know what I mean. Typical purchase office guerrilla tactics I would say.

Is the world going to be multihypervisor? Well... see above. I would say so. It would be like trying to stop a running train with a finger. I bought this. There are a few things, however, I am not buying into.

What I can't really buy into is that there is a magic that allows you to assemble those different platforms as if it was one (cloud). Someone tried a similar experiment before and it didn't work out well. See picture below.

I call this the Frankencloud. I have already touched on this concept in my The ABC of Lock-in post (make sure you read the comments).

What I can't really buy into is that you do this for efficiency. You are essentially creating distinct, separate, incompatible buckets of compute, storage and network resources. This is either under the management of a single entity (IT) or, as Vanessa Alvarez experienced first hand talking to a customer, by a separate independent business unit:

Imagine the cost associated to replicating every single aspect of the ecosystem that needs to exist around every hypervisor deployment. Take backup for example. Find a single tool that is able to backup homogenously all of your hypervisors of choice, including ESXi, Hyper-V, Xen and KVM. Most likely you will end up with having to deploy (and master!), if not 4, at least 3 tools to accomplish the result.

In the final analysis I can't really buy that what you are selling me here is... cloud. Sorry about that. Cloud is about simplification by removing overlaps and complexity. What we are doing here, at best, is replicating the technology sprawl that was typical of the eighties and nineties and that led to insane levels of inefficiencies.

As usual, Steve Chambers shared a few words of wisdom on the topic that I captured in a tweet:

Will multihypervisor deployments happen? Yes they will, at the cost of additional complexity, fragmentation and inefficiency. Will vendors continue to sell the illusion of being able to manage multiple hypervisors as if it was one? Of course they will, it is a great check-box to have for RFIs / RFPs! There are a lot of customers out there that want to be "open" but don't really appreciate what that means (yet). See again my The ABC of Lock-in post.

If you are conscious about the fact that you are going to stand up 2, 3 or 4 separate silos (aka clouds) and you see value in doing that... then I believe you should do it. Go for it. For whatever reason  you have in mind.

If, on the other hand, you still believe in the Frankencloud... then I wish you good luck.

Public Cloud Implementations

The Public Cloud use case is a totally different story.

If you are an Enterprise you are in control. If you are an Enterprise you craft your own strategy. If you are an Enterprise you don't need to relate your strategy to anything that goes beyond what you actually need as a self-contained organization.

But if you are a Service Provider, your strategy is a function of the strategy of your customers (or prospects). This obviously assumes you believe in hybrid cloud and it also assumes that the market is not going to be 100% VMware.

This isn't to say that hybrid cloud is the best of all options we have. Pragmatically, this is to say that..

  1. if the world was only private then public clouds wouldn't exist.

  2. similarly and obviously an all-public-cloud world isn't an option (for this century at least).

So what's left? A mix of both. Hybrid, right.

The only thing I keep hearing from the big SPs is this:

  • "I need to have different hypervisors and stacks that will allow me to sell to all flavors of customers out there, regardless of which hypervisor they have chosen".

Fair enough.

If you are a big name you probably don't want to limit yourself and you probably want to open your infrastructure regardless of the choice that customers made. In other words I think that customers should standardize on a single hypervisor but this doesn't mean all customers are going to choose the same hypervisor. Of course there are some SPs that can afford to focus on a single platform because that is possibly going to generate enough business for them and for their model. Especially if that platform is being used by the majority of the Enterprises that could federate with the public cloud offerings. These SPs will trade off the richness of their offering with simplicity of operations.

The net of this, if you are a (big) Service Provider that wants, possibly, to federate with all of customers out there, you have to have a multi-hypervisor strategy. That isn't an option. Easy.

The discussion then becomes... what do you do with those platforms? Do you make them look like a Frankencloud or do you treat them as separate silos? I'd tend to say the latter but perhaps I should expand more in a future blog post.

Massimo.