What is Cloud Bursting?
A good definition for cloud bursting can be found here:
Cloud bursting is an application deployment model in which an application runs on a private cloud or data center and bursts to a public cloud when the demand for computing capacity spikes. 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 - 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 as Neal articulated in his eBay study, practically speaking, it remains an interesting theoretical model for the most part due to the technical challenges involved in implementing this model.
Let me explain...
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
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 which supports the same API.
With this it makes a lot of sense to connect both ends of OpenStack clouds into one virtual cloud.
We can also see Amazon starting to partner with private Cloud solutions that are based on the Amazon API through their partnerships with Eucalyptus, as well as Citrix’s recent announcement with Cloud Stack.
That basically solves one of the more complex challenges of the lack of consistent data-center models between private and public clouds.
While this is a great start it still doesn't address all three challenges that I outlined above.
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.
So 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. The 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 - This approach is similar to the way Content Distribution Networks (CDN) work today. With this approach we maintain 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.
With the federated deployment approach, we need to keep the data replicated between the private and public site…but how do we do that?
1. First we need to create a separate private data cloud and public compute cloud. When we’re dealing with vast amounts of information, we simply can't burst data with the load, since depending on the amount of data involved, this process alone can take hours. A more practical approach would be to create a separate private data cloud in which each data cloud is physically located close to the location of the public compute cloud data center. In this way, we can have better control over the network latency when we start to burst loads, just like a CDN, only in this case we apply it to transactional information and not just static files.
2. Then, we launch the data cloud on demand. Even though, in most cases it’s not practical to burst data with the load, it is still a requirement to be able to launch new data clouds without any downtime or impact on the existing data clouds. The challenge of doing that over transactional data is huge, as we not only need to replicate the data to the new site but do so while the data keeps on changing as the new site is launched.
Example: Bursting Workload & Data between AWS and Rackspace/OpenStack
The following example demonstrate a simple web application with Global load-balancer (Rackspace load balancer), and Web Application (Petclinic) based on Tomcat as the Web front end and MySQL as the database.
You can read the full detailes including code references of this examaple on Dotan Hortvitz post Bursting into the Clouds – Experimenting with Cloud Bursting
Cloud bursting comes with compelling economic benefits that will enable us to get the best out of both the private and public cloud worlds. In reality, the challenges involved with creating a true cloud bursting environment has kept it in the realm of a theoretical model for the most part until now.
The availability of OpenStack (and to a lesser degree EC2) in both private and public environments can simplify the process of building cloud bursting environments, as now we can have the same underlying data center infrastructure for both environments.
To run real transactional workloads over a cloud bursting environment, we need to address other challenges such as consistent configuration and setup of our application stack, and the hardest part is managing consistent data across sites.