Bridging The Gap Between Private And Public Clouds
Scaling IT means using tools and services on both sides of the cloud divide
Continued from page 1
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 centre. These essential business operations are more likely to succeed if there is a bridge to a physically separated facility. While there are a host of concerns when executing a BC/DR move across data centres, 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 authorised 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.
Challenges
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 synchronising 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 minimise 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 organisations that are in the market for a IT competitive edge.
