Bridging Private and Public Clouds

Scaling IT means using tools and services on both sides of the cloud divide.

A divide as real as any weather front separates private, wholly owned data centers from public, capacity-for-hire cloud providers. There is a role for IT in creating a bridge across this divide as virtualization of all types enables more efficient application development, virtual machine provisioning and business continuity.

A bridged private/public cloud promises efficient workload relocation and an evolutionary path to more cost-effective IT operations. However, the challenges to building a bridge between private and public clouds are real. Aside from the emerging nature of cloud computing technology, IT managers must work with developers and business managers to ensure that development platforms, management controls and compliance issues are aligned between the private and public platforms in order to reap these benefits.

Debate Terms

Before covering what can be done with a bridged private/public cloud, I'd like to start with some basic definitions. In May, NIST (National Institute of Standards and Technology) issued a draft publication titled "Cloud Computing Synopsis and Recommendations," which described the essential characteristics of cloud computing as an on-demand, self-service of resource pools that are rapidly elastic and provided as a measured service. To this I'll add multitenancy, in the form of segregating traffic from one organization or business unit from another.

NIST outlines several deployment models. The most important of these cloud infrastructure models are private, operated solely for an organization either on- or off-premises; public, available to the general public and owned by an organization selling cloud services; and hybrid, which is a composite of the two. In a hybrid cloud, the public and private compute environments remain unique, but data and applications are portable between them.

The newly formed ODCA (Open Data Center Alliance), an independent consortium of global IT users, also just released its first usage models. These usage models are recommendations from IT users that have a longterm view of data-center requirements, including one for virtual machine interoperability between different virtualization platforms and portability between infrastructure providers, which is an essential component in bridging between the private and public clouds.

While there is a debate of epic proportions about the definition of private and public cloud computing, for IT managers the more important questions are when might it make sense to build a bridge between a private and public cloud so that the business gains a competitive edge? And what will it take to integrate on-premises infrastructure with that running in the public cloud?

Why Build a Bridge?

Application development was among the first beneficiaries of x86 server virtualization and set the stage for running infrastructure on site and in a hosted environment. Setting up test and development environments composed of virtual machines that could be rapidly provisioned and de-provisioned on shared resources was also a driver for using public cloud services including AWS (Amazon Web Services). Corporate users can use architectural guides today to move workloads from private to public, enterprise-class cloud providers. For example, VMware partners with public cloud infrastructure providers including Bluelock, CSC, Terremark and others using its VMware vCloud Data Center Services.

In this case, the private/public cloud bridge connects infrastructure (usually processing, storage and networks) or platform (which usually adds to this the operating system and database) so that applications can be built using familiar tools. These cloud "as a service" offerings are referred to as IAAS (infrastructure as a service) and PAAS (platform as a service).

One of the earliest thoughts behind creating a bridge between a private and public cloud IAAS or PAAS implementation was to support essential computing workloads without buying all the underlying hardware infrastructure. And an early example of this was "cloud bursting," or the on-demand creation of IT systems to support peak demands. It turns out that workloads are more likely to expand and contract within either the private or the public cloud as opposed to moving across the boundary on a bridge. However, this could be an effective use case in the near future if ODCA virtual machine portability guidelines are broadly adopted. For now, this functionality usually needs to be built into the application.

BC/DR (business continuity and disaster recovery) plans don't have much chance of working when confined to a single, physical data center. These essential business operations are more likely to succeed if there is a bridge to an physically separated facility. While there are a host of concerns when executing a BC/DR move across data centers, this could be a use case for bridging a private and public cloud.

Bridging to support peak demand or BC/DR also means taking into account data security including authorized access. In addition to ensuring workload portability, the Open Data Center Alliance usage models go into detail when describing how cloud providers should be able to assure secure access while also demonstrating how identity, applications and data use are monitored to meet compliance reporting guidelines.

These are still early days for bridging private and public clouds, which means we are uncovering potholes, both intentional and accidental. Our work at eWEEK Labs has shown that synchronizing workloads on private and public cloud platforms can be tricky. For example, an application workload created as a VMware virtual machine, which results in a .VMDK (Virtual Machine Disk Format), must be converted to an AMI (Amazon Machine Instance) in order to run on Amazon's EC2 (Elastic Compute Cloud). It's possible to convert most workloads from one format to another, but this must be taken into account up front in order to minimize problems. This points to the importance of separating the application from the underlying image in order to increase deployment flexibility.

There is a fair amount of trepidation about the suitability of a public cloud infrastructure for running workloads that handle regulated data. While the feelings of unease are warranted in the short term, regulatory concerns will likely be overcome in the medium term. IT managers should ask questions that show that a public cloud provider can meet the same level of compliance as that of a private cloud. Once these questions have been resolved, then a private/public bridge project can be assessed on the technical and cost merits. The disquiet about bridging private and pubic cloud infrastructure likely also arises from the newness of cloud computing.

Amazon's EC2 exited beta in 2008. IAAS and PAAS for the enterprise are emerging technologies. The fact that NIST and the ODCA have just in the last month released drafts and first versions of their guidelines tells us this is an area for early adopters, an area that is often foreign to enterprise IT managers.

Even though the idea of using private and public cloud resources in concert is new territory, the technique has potential as fertile ground for organizations that are in the market for a IT competitive edge.