What is Cloud Bursting?

May 4, 2012 Off By David
Contributed Article.  Author: Nati Shalom, CTO of GigaSpaces Technologies
CloudCow Contributed Article
 

What is Cloud Bursting?

Cloud bursting is an application deployment model in which an application runs on a private cloud or datacenter and bursts to a public cloud when the demand for computing capacity spikes. A burst is a specific amount of data sent or received in one intermittent operation when a threshold is reached. The advantage of such a hybrid cloud deployment is that an organization only pays for extra compute resources only when they are needed.

The Business Impact of Cloud Bursting

Neal Sample the former CTO of X.commerce at eBay gave an interesting talk last year on the economic benefit of Cloud Bursting. Neal pointed out eBay traffic statistics and showed some real numbers of the business impact of bursting peak load activities using on-demand cloud resources as presented in the diagram below.

 
 
The diagram shows real traffic statistics on eBay site (the brown lines).

The line at the top shows the associated costs for provisioning all the resources for peak loads. The blue lines show what the cost could be if they’d provision for the average load and use on-demand resources for the peak loads. Based on this case study, cloud bursting can yield a 40% reduction in overall costs.

The challenges with cloud bursting

While the economic model of cloud bursting can be very compelling, practically speaking, it remains largely a theoretical model due to the technical challenges involved in implementing it.
Let me explain why…

To make cloud bursting a practical reality you need to address the following:

1. Network connectivity between the private and public site
2. Consistent environment setup
3. Data/Security model

What’s changed?

The availability of new OpenStack public clouds from both HP Cloud Services and Rackspace makes it possible to create private and public clouds using the same underlying cloud infrastructure supporting the same API. With this capability, it makes sense to connect both ends of OpenStack clouds into one large virtual cloud.

We also see Amazon starting to partner with private Cloud solutions based on the Amazon API, through their partnerships with Eucalyptus, and with Citrix’s recent announcement with Cloud Stack.

These partnerships help solve one of the more complex challenges of the lack of consistent data-center models between private and public clouds.

This is an important first step, but challenges remain…

Making cloud bursting a practical reality


1. Network connectivity

To address the network connectivity issue, we can use one of these two approaches:
 

  • Virtual Private Cloud – With this approach we create a VPN tunnel between the private and public network making the network look like one big IP network. A good reference on the various solutions in this category can be found here.
  • Load balancing web traffic (with a federated deployment) – in this approach the private and public site remain isolated from each other from a network perspective. What we’d need to do is use a global load balancer to route traffic between the private and public sites so the only connectivity is at the global router.

2. Consistent environment

In order to burst our private cloud activities into an on-demand public site, we need to be able to fork the exact set of services and application setup that we have on our private cloud, and push it to the cloud. To this end, we need to use automation and configuration tools that work in pretty much the same way in both environments. Tools like Chef do a great job with automating the installation and configuration parts, this partnered with Cloudify recipes enables us to leverage Chef recipes for setting up the installation of the individual services and Cloudify for setting up a complete deployment of any application stack on demand on both private and public cloud.

3. Data/Security

Obviously, bursting processes is one thing, but bursting data is a completely different ball game. Bursting data is one of the hardest challenges with cloud bursting today. There are basically two options when dealing with data in a cloud bursting scenario:

1. Primary site approach – Use the private cloud as the primary data site, and then point all the burst activity to that site.
2. Federated site approach – Much like how Content Distribution Networks (CDN) work today, a federated site approach maintains a replica of the data available at each site and keep their replicas in sync.

The primary site approach is usually the simpler of the two, as it doesn’t involve data movement.  That said, it may open latency and security challenges, as it works on the assumption that every public site needs to have complete network access to the data at the private site, and at a latency that is reasonable. There are still many cases where these assumptions don’t apply. For these cases, a federated deployment approach is the only option.

Final notes

Cloud bursting comes with compelling economic benefits that will enable us to get the best out of both the private and public cloud worlds. To date, the challenges involved with creating a true cloud bursting environment have kept it in the realm of theory.

However, today with the availability of OpenStack (and to a lesser degree EC2) in both private and public environments we can simplify the process of building cloud bursting environments with the same underlying infrastructure.

To run real transactional workloads over a cloud bursting environment, we will need to address other challenges such as consistent configuration and setup of our application stack, and the complexity of managing consistent data across sites. But we are making progress and we’ll continue to see theory become reality for today’s businesses.

###

To hear more on this topic join GigaSpaces at the Cloud Computing Summit at The DevOps PaaS Infusion Meetup in NY May 17th http://meetu.ps/9PpQC.
 
About the Author

Nati Shalom is the CTO and founder of GigaSpaces and founder of the Israeli cloud.org consortium.