The business aspects of cloud: Part 9 – And then there are the challenges of cloud bursting

[#1]

Over the last couple years, I’ve asked many CIO’s about the efficiency of their datacenters. Most did answer me it was somewhere between 10 and 15%. In other words, on average, servers are performing valuable work two to three hours a day on average. There are many good reasons why that’s the case. Virtualization can improve this. A McKinsey study, titled “Clearing the air on cloud computing” states that, through aggressive virtualization, efficiencies of around 30% can be reached. We have just doubled the efficiency of our servers, great.  But at the same time, they are using floor space, energy, management attention, etc. to do nothing 70% of the time.

Can we do something to improve this further? The reason we are limited to 30% efficiency is due to the fact we are aiming to address 100% of our needs with our own datacenter and that needs vary within the course of the day, the month, the year. There are month and year-end jobs, marketing campaigns, seasonality needs etc. But do we really need to deliver 100% of our needs ourselves?

The strategic service broker

In part 3, we discussed the vision of the CIO as the strategic service broker. And we identified that some services no longer need to be delivered by the internal IT assets, but can be sourced from service providers. For those, we don’t really care about server efficiency as we pay per use. In subsequent parts we reviewed the criteria for defining which services can be sourced that way.

We also identified the services that have to be delivered by the IT department themselves. And then, we have the gray area, services that could move outside but that we tend to keep inside due to the proximity of the data. Could I reduce the amount of servers I’m using to something like 70 or 80% of my maximum capacity?

And then there is cloud bursting

What happens then if the user chooses an internal service, but no resources are available to run the services on the enterprise cloud? Obviously, there are other clouds around, couldn’t we just ship the service over to that other cloud and run it from there? Actually that’s the whole concept of cloud bursting.

Cloud bursting is defined as an application deployment model in which an application runs in a private cloud or data center and bursts into 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 when they are needed.

Sounds easy isn’t it? Unfortunately reality is a little more complex. Let me try describing what needs to be taken into account.

There are a number of aspects to look into. Is the service allowed to run outside the walls of the enterprise? If yes, we could provision one or a number of virtual machines on an external cloud, set-up the service, transfer the data and run it from there.

But, that’s actually easier said than done. How much data access does the service actually need, where is that data at the present time, and how sensitive is it? If the amount of data is small and not very sensitive, it makes sense to transfer the data and run it from there. I have been discussing how to integrate data between clouds previously. The approaches are perfectly usable in the case of bursting.

What if the application cannot be run outside the boundaries of the enterprise? Well, here is where we really get an issue. Fundamentally there are two ways to approach this:

• Are there one or a couple services that have lower priorities? You know some of these background tasks that can be halted temporarily to make servers available for the task. That’s the easy way of addressing the problem; however it may make the users of those background tasks rather unhappy as their applications are delayed.
• Alternatively you migrate another service to the external cloud, one that is allowed to run externally, making space to run the core service internally.

This latter scenario requires an explanation. Ideally, we should take the virtual machine and its associated data, push it to the external cloud and run it there. But that would mean that the internally set-up virtual machine runs in the external cloud environment. In other words, that those two clouds are compatible. That’s not always the case at the moment. Many private clouds run VMWare, while public clouds typically use KVM, Xen, Hyper-V or another hypervisor, making compatibility difficult. Standards are currently being developed, but no standards have been agreed upon yet. Today, the chances of this to work are extremely limited.

The other approach is to stop the current service at a predefined point, to provision the same service on the external cloud, to transfer the data and restart it. Such approaches are used in redundant systems, and are called “cold standby.” There will be a delay in the execution of the service that is transferred, but place is made for the initial service to be provisioned behind the firewall.

Conclusion

As you can see, the term “bursting” covers multiple concepts. Although the term is often used as a key approach in cloud, it is not that easy to implement. But it helps improve the efficiency of the datacenter and reduce cost.

When debating where to put your applications, you may want to keep some applications with bursting capabilities in the private cloud, particularly when the workload of your core services varies drastically over the course of the day, the week, the month or the year.

[#2]

Christian,

Great series here, thanks for putting it all down.  There is a statistic that I have been using in my presentations to customers and such and that is from Gartner: "Through 2015, fewer than 2% of applications will be able to effectively "burst" into the cloud while running in the data center." so basically unless companies are prepared to rewrite their applications this hybrid cloud is about what to run where, no so much "cloud bursting". 

Thoughts?

Cheers

Michael

[#3]

Note that cloud bursting is not only on the VM level.

From an infrastructural perspective yes, I understand.

But not only VM if you take it from an application and platform perspective.

In the situation a public cloud provides a PAAS where your software can run on and is able to receive the program and relevant data, it can do the scaling/deployment itself automatically without your VM. If the bursting is somehow regular, you can even have an SLA where your application code is already at the provider side and only the burst request including data is 'bursted'.

Same challenges ofcourse exist, regarding security, integration, data synchronisation, etc.

See picloud.com for an example.

[#4]

Actually there are two different concepts in cloud bursting. I discuss them, but may not highlight them clearly enough. So let me try again:

• One aspect of bursting is provisioning of an environment (VM, application, platform etc.) on an external cloud, on which you then configure the functionality you wish to configure. So, for example, you want to run a copy of a java program on an external cloud, you provision a VM with a java environment embedded into it, install your app on top and get going. If you need a special version of java, you may just provision the VM, then install java and then your app.
• There is a second aspect, and this is to migrate a live VM (with all its content) from one environment to the other. This requires a lot more standardization across the environments than the first one obviously, and can typically not be performed today due to lack of standards. Hence HP's move to Converged Cloud.

The data access is a different element all together and depends on the quantity of data, the sensitivity of data etc. You may or may not decide to "burst" the data from one cloud to another due to those factors. Different approaches exist. I'll probably come back to that in a future blog entry.