Xen and KVM use cases – the value of choice for cloud providers

Steve Higashi - Cloud Architect

Steve Higashi
Sales Engineer

There are many factors that service providers have to consider when they choose their cloud management platform – but I think choice is one of the most important.

What kind of choice? The choice of virtualization technologies they are most comfortable with – Xen or KVM. The choice of storage, network and other features to build into a public cloud product. The choice of what works best for their environment, and what works best for their customers in the cloud services they will launch.

In this blog, I will try to explain why I think choice is critical; why familiar public cloud services focus on one approach or another; and why building a public cloud with the choice between Xen or KVM is better than just one or the other.

Hypervisor history: AWS and GCE

Public cloud providers like Amazon and Google offer one infrastructure solution for every challenge. Amazon’s is based on Xen. Google’s is based on KVM. This, to me, is too restricting.

First and foremost, these choices for most public cloud solutions were made out of necessity, rather than being about offering the “best” solution. When AWS was born, there was nothing out there but Xen. Compared to building a solution from the ground up, it was a better, more cost effective decision for Amazon.

Google, on the other hand, is well known for its long history with the Linux kernel and its development, which meant that it was already intended to be used with GCE (Google Compute Engine). Xen was the best option for Amazon. KVM was the best option for Google.

Does that make them the best option for a customer? Maybe not. Why? Because, as a customer, you must adapt to the infrastructure provided, instead of truly having the freedom to tailor your cloud to your needs.

Why choice is important in the cloud

Limiting choice for a customer means limiting the freedom to choose the environment or environments that work best for them. Having no choice is bad for you as a service provider, too.

If you only offer one option, and another opportunity arises to increase revenues – but your current solution doesn’t support it – you’re in danger of losing out on that revenue. You could find other solutions to work with to get a customer off the ground, or to get your projects to work as intended, but you end up managing a theme park of cloud platforms, just to give your customer what they need. It’s more overhead, more headaches and more inefficiency all round. A shift in your bottom line, and not a good one.

Why OnApp took a different approach

Choice is good. It means you can give customers the freedom and flexibility they need. And helps you save on the cost of implementing, integrating and managing multiple cloud platforms.

In my own experience, from my service provider days, it was always the case that every customer wanted something a little different – and it was increasingly difficult to cater to their needs when choice wasn’t there.

At OnApp, we decided to be more open and allow more agility and flexibility in our IaaS solution. We come from a service provider background: at a fundamental level I think we’ve understood the importance of choice from day one.

How does OnApp give cloud customers choice?

With OnApp you can segment your cloud into different virtualization segments, or “zones” as we call them. Each zone can have its own use case, run on its own virtualization technology, offer its own storage and network options, performance and resilience options… and it can all be under the same control panel. That means you, as a cloud service provider,  can manage everything through a single UI.

Let me take you through a few scenarios. This should give you an idea of how to offer a solution that best fits your customer base, or give you ideas on how OnApp can help you build a new product/revenue model.

OnApp Cloud Use Case Examples

Example 1:

Example 1 shows a simple cloud with two zones. Each zone has five hypervisor servers/compute nodes. One zone is KVM-based; the other is based on Xen. Both use OnApp Storage, the software-defined/distributed storage system built into the OnApp cloud platform.

Zone 1 – Xen

Xen is being used for its ability to run Windows applications and is more suitable to the needs of this environment (I discussed this in my previous Xen vs KVM blog.) This Xen-based zone specializes in storage tiering – a feature built into OnApp Storage – because the cloud provider wants to offer different tiers of service to suit different budgets and performance requirements.

OnApp Storage lets you create storage tiers with different price/performance for different workloads, using SSD for “High Performance” (e.g. workloads based on high transaction databases), 15k SAS/SATA (for mid range performance) and 7.2k/4k spinning disks for more general data storage or archiving. You can also use OnApp Storage to create zones that emphasize replication (i.e. resilience) as well as performance.

Using storage tiers enables the provider to distribute workloads across its infrastructure – in this case, to handle the load of the multiple MS SQL DBs running on the environment. By being able to move the SQL DB to another storage tier, you remove the stress of a single storage volume VM.

Zone 2 – KVM

This second zone is KVM-based. KVM is generally preferred for Linux-based VMs, and here the cloud provider is also offering different tiers of storage. So, by offering Xen and KVM zones, the provider offers multiple choices for deployment, each with a range of storage options.

Example 2:

In this example, the provider has built two zones: one based on OnApp Storage, and one based on a hardware SAN. While most OnApp cloud providers use our software-defined storage system, it’s often the case that they already have a proprietary SAN and want to build that investment into their cloud value proposition.

Let’s face it, hardware SANs cost money, so why not use them if you already have one or more? OnApp sees external SANs in just the same way, as storage devices you can also tier – based on LVM volumes – giving you many different options to build proprietary SAN storage into your cloud.

In  example 2, the provider is offering choice based not just on virtualization type and storage tiers, but also compliance – offering cloud infrastructure in specific locations, to cope with data sovereignty legislation, and with specific industry compliance standards (HIPAA, ISO, SAS70 etc).

This can be extended further with tiering of other infrastructure resources, like compute and networking – all sold, provisioned and managed through the ‘single pane of glass’ OnApp control panel.

In conclusion…

A homogenous cloud might be good for one environment, one client, or solving a single challenge – but as a service provider, if you don’t offer choice, your customers will just go find what they need elsewhere.

The OnApp cloud management platform gives you multi-layered cloud stack that enables you to offer numerous combinations of storage tiers, both public and private, with self service, different billing options, different network performance, additional virtualization technologies – and so on. Even if you specialize in one thing, the choice is yours to expand your service offerings, or custom tailor everything to meet your specific business model.

Want to learn more?

Never stop offering choice to your customers!  If you’d like to know more about using OnApp to sell multiple cloud services, just fill out the form. Thanks!