There has been quite a lot of twitter traffic about the FrankenCloud recently: A cloud with more than one type of hypervisor underneath it. One example, is to build a cloud using Hyper-V three and vSphere, both managed through Microsoft System Center. Another example, is to build a cloud using Hyper-V, KVM, and vSphere all managed through HotLink. But is this a desired cloud topology?
But before we begin: In the early 90’s a little known startup came out with a beta of a type 2 hypervisor that would benefit developers more than servers, that company was VMware. When this product became available, one of my long term computing goals was starting to be met.

The ability to run any software product I wanted, regardless of computer type.

Back then, I used a Macintosh IIsi and was serious considering an Orange Micro PC card to plugin into the machine. However, I never added the card. Instead, I suffered through several more years, exchanging my IIsi for a set of higher end laptops and eventually ran windows workloads within virtual machines. Actually, I converted my physical box to a virtual desktop in a matter of hours (mostly to copy the data) within an early version of VMware Workstation.
This environment grew and one day, my windows laptop ceased to function and I picked up one of the new breed of devices from Apple Computer, and suddenly my goal was met. I could run any application I wanted, whether it was UNIX, LINUX, MacOS, or Windows based, all from one machine. Yes, I added some management complexity by using VMware Fusion. The key here was ‘regardless’ of operating system. In essence, the operating system and underlying hardware upon which that operating system was no longer a limiting factor.
But the hypervisor did become the limiting factor and in many cases and still is today.  Why is it limited? Because it is tied to the x86 hardware architecture at the moment, but even more so, because I am limited by the hypervisor to what type of hybrid cloud I can have moving my multi-os servers and workloads forward. If you are running a vCloud based environment within your local data center, for example, the chances of an OpenStack Cloud being used as a part of your vCloud based environment is rather limited.
It is limited in the ways in which you can move workloads into the cloud, how you can manage the remote aspects of your hybrid cloud, and how you can automate workload deployment and shutdown of workloads during peak hours. On top of this, the security of your hybrid cloud comes into question. Even when we use like to like hybrid clouds we have some issues moving workloads around. Here is my new goal:

To have a hybrid cloud that can be managed from one location and just runs my normal and burst workloads in a secure fashion.

There are several problems we face with hybrid clouds:

  • How do we move workloads into the cloud?
  • How do we burst workloads into the cloud quickly and efficiently?
  • How do we secure the existing and burst workloads?

In essence, how do we meet the goals of the business? This is the real question into which all the others fall. So what are the problems today?

  • There are very few replication receiver clouds available, which limits how workloads can get into the cloud. We can create the virtual machines, then either migrate or replicate the data.
  • We need to have virtual machines already created and configured to burst workloads quickly into a cloud. Even with heavy automation, we need standby workloads ready to boot, or perhaps hot standby workloads that are ready to be added into a load balancer for example. It takes time to deploy gigabytes of data even with highspeed 10G networks.
  • There are not enough clouds available that meet our service level requirements. If we need 5 9’s of uptime, we will not get that with all clouds. If we need special security, we cannot get that with all clouds that use the same hypervisor.
  • Clouds can be expensive!

Given the time constraints, business requirements, and service level agreements, why are we concentrating on just like to like hybrid clouds? Instead, I want to concentrate on the best clouds for my business regardless of underlying hypervisor technology, and if that means I have part of my workloads within a vCloud, part in an OpenStack Cloud, and another part in Azure, then why is this a problem if I can manage all of them from my local cloud environment?
Yes it may look like a FrankenCloud, but it is managed from one location which controls how my workloads are deployed, how data is replicated into and out of the cloud, and how my business runs. Granted, going this route could change my data protection and security tools to a different non-hypervisor specific set of tools or ones that span all the hypervisors in use within the FrankenCloud. This is where vendors that span or are independent of hypervisors come to the fore for IaaS based hybrid clouds. But for SaaS based cloud services, we already have FrankenClouds.

4 replies on “Enter the FrankenCloud: Or Do we really care about the Hypervisor?”

  1. No, this is not Frankencloud. Frankencloud is a cloud built (by the provider) on top of various hypervisors. You want to leverage (as a consumer) multiple clouds for deployment of your applications. This is valid use case and there are tools and common APIs that try to accomplish this. For example VMware Application Director.

    1. Hello,
      I see this as a Hybrid FrankenCloud. Whether your mixed hypervisors are local or remote in an IaaS hybrid cloud you still run into the same management, business agility, and security issues. How can one manage, secure, and respond to security issues when the cloud layers above depend on the specific hypervisor?
      Best regards,
      Edward

  2. Perhaps the word FrankenCloud is a bit too strong and will trigger emotional reaction instead of logical thinking. I don’t have a better word for it though, as I believe the technology is not ready for a mix platform. Hypervisor is no longer a standalone component, hence viewing it as a simple layer is wrong. There has to be better integration at vCenter layer by various cloud vendors (MS, VMware, Amazon, etc). Until such time, it does not make sense to have multiple platform. It is like having 2 different emails (e.g. Exchange and Notes) or 2 different directories (e.g. MS AD and Oracle) or 2 different office suite (e.g. MS Office and Open Office).

    1. Hello Iwan,
      I would agree, but we see people using multiple hypervisors today in their environments, we also see 2 different mail servers (with one forwarding to another), and multiple directory servers (depending on type of OS) as well. So this implies to me that the first to come up with a usable unified management tool could be the big winner. At the moment we seem to be arbitrarily limited in our cloud choices by hypervisor instead of SLAs.
      Cloud (Hybrid or otherwise) is by no means unified today. But it should be our goal.

Comments are closed.