Friday, November 04, 2011

Three Approaches to Building a Cloud

In the course of preparing for the Red Hat Cloud Tour, I (along with many others on the Red Hat cloud team) gave a lot of thought as to how best to articulate the value delivered by cloud computing, what's needed for a private or hybrid cloud environment, why you'd want to build a cloud in the first place, and which approach delivers the greatest value.

Let's talk about that last point with the aid of a few slides from my keynote presentation from the Cloud Tour.

The typical IT operation can be thought of as consisting of a set of silos. Some of these silos may be the result of deliberate plan--perhaps to meet some regulatory need to keep internal businesses completely separate. However, more commonly, they come about through the accretion of new technologies, products, and organizations. All these silos create complexity. One goal of implementing a cloud should be to reduce this complexity.

How best to proceed?

This first approach essentially attempts to translate the "Greenfield" methodology used by service providers into an enterprise environment. The thinking is that throwing out existing infrastructure and replacing it with a grounds-up, homogenous, standardized computing foundation is a dramatic simplification relative to the typical enterprise IT infrastructure as it exists today.

In fact, this approach does dramatically simplify. It's also naively simple. For the vast majority of organizations, IT assets tarred with the pejorative "legacy" are also critical and core to the business. More broadly, IT infrastructures advance in an evolutionary way rather than through wholesale replacement. Doing so keeps both risk and cost down. Cloud computing is no different. While infrastructure standardization, modernization, and simplification are frequently good practices, they can usually only be taken so far.

Suppose, instead, we tackle just part of the problem. There are a couple of different ways to go about this.

We could, for example, decide to add some self-service and automation to a specific virtualization platform. This is VMware's approach to cloud. vCloud Director essentially just extends the vSphere virtualization platform and therefore requires that the underlying platform, whether in a private or public environment, be running a VMware technology stack. Alternatively, we could roll in a dedicated cloud appliance for some single purpose, such as a database.

Whichever of these two paths we take, the result is the same. Our IT infrastructure now has another silo. Hardly a reduction in complexity!

This is not to say that we can't start our journey to a cloud on a subset of infrastructure. In most cases, a pilot project or proof-of-concept using a subset of applications will indeed be the prudent path. The difference is that a proof-of-concept is a first step; a new silo is a dead end.

The final approach, and the one that Red Hat advocates, is to enable bringing the broadest set of IT assets under a cloud management framework. Certain existing--often static--workloads may be kept separate for a variety of reasons. But such decisions should come about because they make the most sense from an IT operational perspective, not because of restrictions imposed by a technology stack.

Supporting these capabilities requires a cloud management product that can span multiple virtualization platforms, a variety of public cloud providers based on a variety of underlying technologies, and even physical servers. While most clouds will have a virtualized foundation of some sort, we have spoken with a number of customers who require blending physical and virtual environments for different types of workloads or use cases.

The Red Hat product that makes this approach possible is CloudForms, which provides Infrastructure-as-a-Service management for private and hybrid clouds. It works across virtualization platforms such as vSphere and the KVM-based Red Hat Enterprise Virtualization and a variety of public clouds starting with Amazon. Its key interoperability component is the Deltacloud API, an incubator project under the governance of the Apache Software Foundation.

I've covered just a small part of our our Cloud Tour content. However, it's an important part because fundamental differences in approach to building clouds lead to fundamental differences in the business value that can be extracted from them.

Post a Comment