The Frankencloud

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.


10 comments to The Frankencloud

  • Phil_B

    Gday Massimo,

    It’s a good analogy, what’s the saying, “the sum of the parts are greater than than the individual components”, well the Frankencloud is quite simply the polar opposite. Like yourself I have talked to many SP’s who are wrestling with the “being all things to all people” and have lost sight of what started, and continues, to drive Cloud adoption, quite succinctly, it’s simplicity. Simplicity for the consumer, simple to deliver, simple to measure effectiveness and efficiency. The “simplicities” are endless.

    The Frankencloud is plainly wrong, IMHO. Another analogy is the 80:20 rule, if we can service 80% of our customers requirements at 20% of the cost, then great and we should be happy with that. If we start spending 80% to service the remaining 20% of our customer requirements then something is going wrong. Multiple Clouds to service wildly differing requirements is perfectly acceptable so long as each in their own right tick the “simple” boxes which includes some level of interoperability. Now that could take us to another of your favorite subjects, the A, B, C of API’s, but that discussion is for another day.

    What I don’t understand is that the Frankencloud is a bad business model (with current technologies at least which may change over time as all things related to IT evolve) yet many SP’s seem obsessed. Unfortunately I believe that the people holding the purse strings are being sold on technology theory and misinformation with the end result bearing little to no resemblance to their idealistic goals. Hence, Frankencloud is perfectly descriptive.

    I too have had the “why multi-hypervisor” discussion with consumers/customers and maybe based on where I live, they are far more candid, most will quite openly say, it’s for commercial reasons. That’s the perfect answer, remove the technology tit-for-tat, get down to basics, solve a problem and get the best (not necessarily lowest) price from your suppliers. Maximise the benefits in the shortest time possible.

    So in summary, a simple yet great post, also, Frankencloud is perfectly descriptive to not only the multi-hypervisor debate (for IaaS) but also the layering of dozens of technologies to try and squeeze out that last 20% in the 80:20 scenario – madness. When delivering my first post-university project for IBM and we were defining the requirements for an automated QA regression testing system for PTF packaging my manager told me to forget all the university theory I had been taught for 3 years and inducted me into the school of “KISS” (I know, quite un-IBM like, he was a maveric). I still totally agree to this day, the first and most simple approach is more than likely going to service you better than anything else you spend the next 12 months trying to invent.

    All the best.

  • There is only one true hypervisor and it’s name is PR/SM (Prism when you’re saying it).

    Sometimes I feel like a jehova’s witness 😉

    “has anyone talked to you about the power of PR/SM yet?”

  • Pete

    > “I want to use another hypervisor so that I can put more pressure on VMware at the next ELA

    Of course. Setup Hyper-V for ‘dev/test’ and get x% off on the next ELA renewal 🙂

    Oh, ”My private cloud is I pick up the phone to IT (probably India) and say “Build me 5,10… x VMs and associated apps.. pronto!” Heck, their already highly paid VMware administrators, so they might as well do something 🙂

  • T

    IMO – Hetrogenity in IT environmet has been a reality for ages. Look at compute or storage architectures. Ideally it should be uniform, single vendor but because of specific use cases, we do have multiple server architctues. Yes, there is complexity in managing them but in the end it is the use cases combined with the ecomonics that drove it. Similarly, multi hyperviso will eventually happen. However, when going down the path, one must select the use ases carefully. For example –
    1. put the dev/test on a lowcost/free (hyperV) and production on another, feature rich (say vmware).
    2. If you have local server rooms that you can’t consolidate to a cental DC, use a low cost hypervisor to virtualize locally cause it is unlkly you nee a feature rich hypervisor for such purposes.

    I don’t think anyone would think of moving creating a vrtual farm/private cloud with multi hypervisor deployment with the objetive of moving the workloads dynamially between them (well,not anytime soon). Tread this path carefully.

    • Massimo

      I can’t say I agree with your points but thanks for sharing them. I agree that this is how it worked lately (for ages)… but this doesn’t mean it’s the right way to do things. Amazon (and I would argue cloud in general) is taking a different approach: for ages we designed infrastructures to support existing applications. IMO cloud is about designing applications that target existing infrastructures. In other words, gain efficiency by simplifying and standardize your infrastructure with as few peculiarities (e.g. hypervisors) as possible.

      See this post from a third party with no vested interested in selling you more stuff:

      As far as costs are concerned.. a couple of points:

      – the little you may save on hypervisor CAPEX… you are probably going to spend 5x on OPEX. Not because one platform is less efficient than the other, but because of the added complexity in managing many different moving parts
      – if you compare the Hyper-V/SC functionalities with the top-end VMware SKUs that sounds an unfair comparison for obvious reasons. You may argue that you don’t need all those fireworks in a remote office, point taken. My point is that if you only need a subset of all the fireworks the two solution starts to become more comparable in terms of pricing (I am not even getting into the “but VMware is still technologically much better”).

      Having this said, as I mentioned on the post, multi-hypervisor deployments will happen. I just don’t think it’s the most efficient way to manage a datacenter.


  • […] And it’s only roughly roughly 400 lines of JavaScript code (without comments)! It’s not a Frankencloud by any […]

  • […] And it’s only roughly roughly 400 lines of JavaScript code (without comments)! It’s not a Frankencloud by any […]

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>