Beware of the cloudburst

Beware of the cloudburst

Summary: A big selling point for cloud computing is what's become known as cloud bursting. What this means is the ability to move spikes in demand for computing resources into the cloud, rather than having to build infrastructure to cope with peak loads.

TOPICS: Networking

A big selling point for cloud computing is what's become known as cloud bursting. What this means is the ability to move spikes in demand for computing resources into the cloud, rather than having to build infrastructure to cope with peak loads. You only pay for what you need, in other words.

It's a bit like having an alternative supplier for commuter trains in the rush hour although -- if the analogy will stretch this far -- having to go to an alternative station to catch one.

This of course lies at the heart of the promise of cloud computing: enabling the agile enterprise, bringing flexibility and so on. But what does it actually mean? And is it really as simple as it sounds?

This train of thought was triggered by a lunchtime conversation with Marten Mickos, CEO of Eucalyptus, which builds cloud software.

The first thing that springs to mind is that applications don't work without data, and moving data around is expensive in terms of time and money, especially if you're paying a cloud provider for storage and bandwidth.

The time element is critical. Imagine: your demand spikes, so you need to shift that excess computing load into a cloud provider's facilities. But the database behind the application is huge and certainly won't be moved in the time available.

Instead, you move that database into the cloud ahead of time. Now you have the problem that you're paying for that storage even when you don't need it, and you need to find a robust mechanism to keep that database in sync with the live data in your private cloud.

What's more, that data is now potentially at risk if it's sensitive, such as credit card details. Is the cloud provider certified under PCI-DSS guidelines to hold such data? And can you recreate the applications' environment in the public cloud such that it can attach to that data in a seamless manner? If not, are the tools available to make it so?

But hold on! I thought that cloud was supposed to reduce costs not start running up a bill for capacity I don't actually need right now.

You would hope that cloud platforms such as Eucalyptus could take some or all of the pain out of this scenario. If so, all well and good. But before you start swallowing the hype about the cloud's instant flexibility, it would be worth taking a closer look at a real world scenario.

I'd be interested to hear real world examples of cloud bursting.

Topic: Networking

Manek Dubash

About Manek Dubash

Editor, journalist, analyst, presenter and blogger.

As well as blogging and writing news & features here on ZDNet, I work as a cloud analyst with STL Partners, and write for a number of other news and feature sites.

I also provide research and analysis services, video and audio production, white papers, event photography, voiceovers, event moderation, you name it...

Back story
An IT journalist for 25+ years, I worked for Ziff-Davis UK for almost 10 years on PC Magazine, reaching editor-in-chief. Before that, I worked for a number of other business & technology publications and was published in national and international titles.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Hi,

    I work for Xeround (, we offer a database-as-a-service for MySQL applications. Our auto-scaling feature was designed to address just such cloudbursts- enabling automatic scaling of throughput/size of the DB tier to handle increasing load, with no management overhead, manual scaling or over provisioning. We automatically scale out when more resources are required, and shrink back down when the database is underutilized- making it suitable for apps with fluctuating demand patterns or that experience unexpected spikes.
  • @avigailof: Perhaps you could share a bit more about how that actually works?
    Manek Dubash
  • While it is great, there are still a few things wrong with xeround being 100% compatible as it is your own custom DB engine. I had moved a DB there only for it to be painfully slower than an EC2 instance.

    Also the limitation on what cloud providers are supported.

    Other than that it is pretty interesting and cheap. But still this article is about having a dedicated server(s) and spiking into the cloud but xeround is already in the cloud and uses cloud providers which means you must be in the cloud already and paying for an account just incase and a minimal account to reduce expenses.

    Also the speed of moving the resources to the cloud...if there is a spike, and you have a 100-500GB database, will xeround scale fast enough? or the same as it would if it were not on xeround? because it is awfully trivial to setup a mysql master > slave but it's replicating that data to multiple slaves fast enough.

    So i don't think xeround even solves anything mentioned here.

    However, i would use it for a start up SAAS, for example due to the cheap cost but not for the issues this article is speaking about.
  • Thanks Eric. You raise exactly the issues that concerned me when I started to think a little more deeply into the concept of flexibility and the cloud.

    It seems to me that relatively trivial loads will be suited to bursting along with compute-only tasks. But what about the rest?
    Manek Dubash