What is a Hybrid Cloud? — A Tutorial

A green soybean field under a blue sky, filled with cloudsIf hybrid cars are “green cars,” what is a hybrid cloud? Can enterprises simply pick public or private and ignore hybrid alternatives, or are hybrids really the best of both worlds?

As we’ve discussed previously, many enterprises are starting their cloud journey with an internal, private cloud. But when you really talk to those same enterprises, most are happy to share that they have plans for a hybrid environment sometime in the future. Sometimes those plans are detailed and concrete, other times just vague and fuzzy. For all the fighting between public and private cloud proponents, the answer given by enterprises is a solid “Both!” So, what is a hybrid cloud, exactly? And why does it make sense to build one?

Start with NIST

As we did in our tutorial on cloud computing and private clouds, we’ll first take a look at the cloud computing definitions published by NIST:

Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

In short, take two clouds (most frequently a private cloud and public cloud) and bolt them together, and you have a hybrid cloud. That seems simple enough, but it generates a set of follow-on questions:

  • How do you bind the public and private clouds together to form the hybrid cloud? What is the “standardized or proprietary technology” that NIST mentions?
  • How do users access the hybrid cloud? How is it exposed to them?
  • What are the benefits of a hybrid cloud?

Hybrid Cloud Technology

For simplicity, let’s pretend that an enterprise has built a private cloud based on a standard virtualization technology (e.g., VMware, Hyper-V, etc.) and picked a public cloud provider (e.g., Amazon Web Services, Rackspace, etc.). Now what? How do we build a hybrid cloud? If nothing is done, the enterprise really has two clouds, one private and one public. Users, for instance, could use one access-technology to interface with the private cloud (e.g., VMware vCloud Director) and another access-technology to access the public cloud (e.g., the public cloud web portal). But that’s not very satisfying. Users have to learn two different interfaces and there’s no way to abstract workloads so they can be deployed easily in either cloud. Each workload would have to be built out to run in both clouds, using different tools for the construction. That’s painful with two clouds; add a third to the mix and it’s overwhelming.


The technology that stitches multiple clouds together into a hybrid cloud is called a cloud management platform. One example is BMC Software’s Cloud Lifecycle Management (CLM) (full disclosure — I currently run solutions marketing for BMC’s cloud, DevOps, and data center automation products). Another popular choice is Rightscale. BMC’s CLM is deployed on the customer premises (the enterprise data center) and manages public clouds out through the corporate firewall. Rightscale is delivered in a public SaaS model and manages private clouds by punching holes back through the firewall. Other products are available from CA, Dell, HP, IBM, and VMware and vary greatly in features and sophistication.


Hybrid Cloud Management Platform

The hybrid cloud management platform performs a number of important functions:

  • Interfacing to multiple clouds. Job #1 for the cloud management platform is interfacing to multiple types of clouds. Without this, you can’t have a hybrid cloud. Beware of systems that support only the technologies of a single vendor or two. For instance, some products support only hybrid clouds based on a single hypervisor, where the private cloud uses that hypervisor as well as the public cloud. That’s quite limiting; one of the most common hybrid cloud constructions, for example, is VMware for the private cloud and Xen-based AWS for the public cloud. While exhaustive support for every technology isn’t necessary, you’ll want to ensure that the system supports the key types of clouds you’re likely to use, both public and private.
  • Unify the interface. Thhe cloud management platform provides a single, unified interface to all the clouds in the hybrid cloud structure. This has a number of advantages. Most obviously, users don’t have to learn multiple interfaces to use all the clouds in the hybrid. Importantly, however, clouds can be added and removed from the hybrid structure without forcing everybody to retrain on a new interface. That’s important because one big tenet of cloud computing is that organizations should not be locked into long-term arrangement, but rather free to shift from cloud to cloud as their needs change. Retraining creates friction and “soft lock-in” which can prevent the enterprise from making otherwise sound business decisions.
  • Abstract, cloud-agnostic workload blueprints. Ideally, when you create a workload to run in the cloud, you do that in a cloud-agnostic manner. Many cloud management platforms call this a “blueprint.” The idea here is that the abstraction, the blueprint, can be placed in the service catalog and accessed through the self-service portal. Users can select the blueprint from the catalog and then decide the cloud in which to instantiate it, based on cost, performance, or security requirements, for instance. The blueprint itself is cloud-agnostic and therefore users can create the same service in all clouds without having to understand the nuances of cloud construction in each cloud.
  • Stack provisioning. Underlying blueprint concept are methods of delivering full stack provisioning, allowing workload creators to build full applications from operating systems, middleware, and application components, building those up using methodical automation. This is important for providing the same, consistent application experience in each cloud. Some cloud management platforms provide sophisticated tools for this; others just expose a simple scripting interface.
  • Policy management. Once you have unified the interface to the hybrid cloud, all cloud requests will be flowing through that system. And that’s a good thing, but it can create problems. Firstly, who is allowed to use the system? Next, even if Bob is allowed access, can he access resources in any cloud that is part of the hybrid or is he limited to just the public or private cloud? Does Bob have the same access rights as Suzy? If one workload deals with secure data, can it be instantiated in public clouds? The policy management system provided by the cloud management platform can keep all these business rules straight. For mid to large enterprise, policy management is critical. For smaller organizations, simple role-based access control might be enough.

The Best of Both Worlds

By creating a hybrid cloud using private clouds, public clouds, and a cloud management platform to tie them together, users get the best of both worlds:

  • All clouds are accessible through the same interface. When a user wants to provision a workload, he can do it the same way every time.
  • Workloads can be placed into the right cloud based on application and workload requirements. Does the workload require a highly secure environment? If so, place it in the private cloud. Is the workload highly elastic, scaling up and down with time of day or the seasons? If so, place it in the public cloud to save cost when it scales back and provide lots of headroom.

The best part of hybrid clouds is that they aren’t limited to just a single public and a single private cloud. You can mix and match multiple clouds to deliver the optimal set of characteristics required by your users and your workloads.

Speak Your Mind