skip to Main Content

Tintri Blog

External Cloud Providers: Exploring Single vs. Multiple Hypervisor Options

May 23, 2012

In this guest blog post on the Tintri blog, vExpert Bill Hill explores the trade-offs between single and multi-hypervisor external cloud providers.

As virtualization takes a strong hold in the data center, virtual machines (VMs) no longer run in a “virtualized” environment: Rather, the term has changed to “cloud.” If you have a hypervisor in your environment, it is your “internal cloud” or “private cloud.” If you use infrastructure from a hosting company, it is your “external cloud.” Running machines in both internal and external clouds is a “hybrid cloud.”

A new market has popped up to support external and hybrid cloud environments. Suddenly, the same companies (and service providers) that provide hypervisors want to enable enterprise IT to leverage external resources and infrastructure to run the very same internal-cloud VMs in their environments. This market is forking into two distinct groups: single-hypervisor cloud providers and multi-hypervisor cloud providers.

Single-cloud products, such as VMware vCloud, focus on supporting a single hypervisor. If you run the VMware hypervisor internally, do not bother trying to migrate VMs to Amazon EC2.

Multi-hypervisor cloud products, such as OpenStack, focus on customer flexibility by providing support for multiple hypervisors. Theoretically, you could move a VMware-based VM and a KVM-based VM to the same hosting provider.

So, the question becomes: In the event you want to utilize an external cloud provider, why would you choose one over the other? There is definitely no right or wrong answer to this question.

First off, why use an external cloud provider (regardless of single vs. multi-hypervisor support)?

This question is the topic of much debate. Security concerns aside, external cloud products provide some interesting functionality. The following factors can help determine the best choice:

  • Spike processing: IT architects design environments to operate at some level of status quo. However, depending on the market (such as Web marketplace), you can anticipate fluctuations in need for production access (for example, Black Friday, or seasonal ordering). These fluctuations must be built into your environment as load balancers — additional servers with more RAM, CPU, storage, network access, etc. This demands additional bandwidth, support and maintenance, power, data center footprint, etc. By enlisting the resources of an external cloud service, you can bring up resources proactively to assist processing of spikes and to lessen the blow on the existing production environment. Sure, some resource requirements are inescapable, but many others can be offset.
  • Disaster recovery (DR) and business continuity (BC): DR and BC require some level of compute resources in a remote location. However, there is nothing stopping a company from using cloud-provided resources for much of the same functionality. One of the biggest hitches is the lack of SAN-to-SAN replication. However, given time, I imagine that this will be addressed.
  • One-offs: Sometimes, you just need another VM for something. Who knows why; you just do. Utilizing an external cloud provider ensures you have resources available. They become a product of convenience.
  • Testing and development: Maintaining separate infrastructure to support development and test needs is significant. Especially with the demands developers can place on the infrastructure, costs can skyrocket (inefficient code using too much RAM, CPU, or IO, new servers, persistent archival old-development servers, unneeded servers). An external cloud provider allows a company to reduce investment in local infrastructure (storage, network and compute) while allowing developers to get access to what they need when they need it. Plus, it makes chargeback easier, as there is a concrete charge for hosting services.
  • Infrastructure as a Service (IaaS): Getting rid of all infrastructure is a pie-in-the-sky scenario for most companies. However, for many, it is a reality. A cloud provider can eliminate the need for local infrastructure and requisite support services. A company interested in IaaS can focus on the application tier without being concerned with the physical layers.

The biggest point to make is that applications really need to be built to scale. They do not need to be cloud-aware, but need some level of WAN functionality or be completely autonomous. If load balancers, reverse proxies, caching, replication, etc. are not available, you may end up doing more harm than good. Cloud is an architectural decision and should not be taken lightly.

Vendor lock-in vs. selection of the most convenient provider

Anytime a vendor has a very compelling product, it is likely you will use it more and more. All of the cool whiz-bang features become ingrained into the infrastructure. Suddenly, you are locked into the vendor’s product. Is that a bad thing? Some would say yes, others would say no. However, one would expect a cloud product provided by or based on a vendor’s product to have deep support for all of the functions you depend on. Plus, the vendor may push out functionality that leverages your investment: More bang for your buck for buying into their product lines.

On the other hand, with a multi-hypervisor external cloud provider, you are not locked into a single product line. Rather, you get the best of many worlds. For example, if you run ESXi for server virtualization and Hyper-V for desktop virtualization, an OpenStack solution provider may be what you are looking for.

Adaptive vs. homogeneous functionality

Products from a vendor are updated, upgraded, add functionality and get overhauls all the time. This is the natural progression of production software. Single-hypervisor external-cloud products can keep up with the development of the underlying hypervisor and adapt to the growing environment. Multihypervisor external cloud products are less likely to stay up-to-date, as they are concerned with maintaining compatibility across all supported hypervisors. One would expect that in the long term, some of the new functionality would be supported, after rigorous testing and implementations.

What is the true value in selecting a multi-hypervisor cloud provider?

Multicloud providers really have a market in:

  • Not letting the MAN keep you down: This gives future flexibility in moving from hypervisor product to hypervisor product. No one vendor will define how you can cloud compute.
  • Fostering competition: VMware remains the big man on campus as far as hypervisors are concerned. By introducing an external cloud product that can incorporate VMware hypervisor, along with Xen, Hyper-V, and KVM, other hypervisor products have the ability to make some headway. The playing field for leveraging external compute resources is leveled that much more.

The fight for relevance and market domination is strong right now. VMware’s vCloud product is highly compelling for VMware customers. However, the cost to play ball is significant and other non-vCloud options exist that are appealing, especially if you do not need all of the integrations and functionality vCloud provides. OpenStack, CloudStack, and Eucalyptus have up-and-coming alternatives that may give vCloud a run for its money.

Cloud computing is not all sunshine and rainbows. The model has to fit your needs. If you decide cloud computing in your future, think carefully about security implications, cloud provider locations, connectivity, integrations into existing infrastructure, and the right provider. External cloud computing has huge benefits; just make sure you get onboard when you are ready and with a partner that can help you along the way — with single or multiple hypervisor support.

Back To Top