Cloud bursting is a rather nebulous buzzword that sounds cool but, I'm afraid, has nothing to do with Kate Bush. Instead, it's the term used to describe a setup where you run your business mostly on your own kit, but also have a set of cloud accounts sitting idle, ready to take on extra "bursts" of work when demand peaks.
Isn't that already the idea behind hybrid cloud?
Yes and no. Hybrid cloud is an umbrella term for dividing up your computing resources across local and off-premises servers; cloud bursting is a specific way of using those resources.
In practice, a cloud burst setup might use containerised VMs and some form of load orchestration package to shift containers to locations where user sessions can reach them. It will probably require quite a lot of work at the database design level as well, so that this too can be replicated, multi-homed or remotely accessed. In short, cloud bursting isn't an architecture or a computing philosophy, but a capability of your entire technology estate.
Is it just an agile implementation of hybrid cloud?
That's a question of semantics. A cloud bursting setup should quickly respond to unforeseen changes in demand, but this isn't quite what's conventionally meant by "agile". Agility is about being able to retool your code quickly to adapt to changing circumstances, whereas cloud bursting requires everything to be in place well before the high-load day comes.
You need to have your cloud accounts in place and paid up, you need to be sure that your code platform will run on the cloud, and you need to make sure that it's actually capable of meeting the demands you want to place on it. Doing this properly involves a great deal of pre-emptive development and testing. I'd be very wary of a business that went into a cloud bursting project with an "agile" mindset.
Is cloud bursting cheaper than regular cloud hosting?
It might work out that way, but the two models aren't perfectly comparable. Hybrid cloud usually tends to imply an IAAS model, whereas cloud bursting finds most interest from heavy SAAS users.
Cloud bursting also relies on your orchestration software correctly working out when to spin up the offsite services and incur the associated charges - which involves an element of voodoo, as it's exquisitely difficult to distinguish between blips and booms as they're happening. A hybrid cloud setup with plenty of slack capacity may or may not work out cheaper, but it's likely to be more dependable, and have a more predictable cost.
When is cloud bursting the right answer?
There are some such scenarios, but they're mostly inside the world of IT itself. For example, if you're an antivirus developer combatting zero-day exploits, you'll want the ability to scale your download links out into the cloud on bad virus days. Some classes of simulation can also easily parcel up workloads and hand them off to compute nodes with no regard for where those nodes are hosted. Unfortunately, this model has become controversial, since it's currently mostly employed by Bitcoin-mining trojans.
What's the key downside of a cloud bursting?
Finance directors probably aren't going to love cloud burst projects, because (as we've noted) the costs are unpredictable by design. What's more, since the whole point of cloud bursting is that you don't use it regularly, it's only when you really need to fire up those cloud servers that you discover that a recent update has unexpectedly broken your meticulously crafted handover routines.
These inherent risks will tend to push most businesses back in the direction of a more traditional hybrid architecture.
Why is cloud bursting billed as the next big thing?
I suspect that the vendors aren't trying to get you specifically into cloud bursting. They want to make you think more generally about where your computing resources live.
A little research, and my own anecdotal experience, suggests that very few companies have actually committed to a full-on cloud bursting model - which probably tells you everything you need to know.
