Minerva Studio - Fotolia
- Nick Martin, Editorial Director
Cloud bursting: the prospect of paying only for what you use has long spurred interest in public cloud computing, from both C-level executives and IT managers faced with lean budgets. A hybrid cloud that can elastically expand workloads to a public cloud provider during peak demand -- and then scale back to the original in-house servers when demand subsides -- tempts organizations with promises of unlimited, uninterrupted service free of large capital outlays.
It's easy to see why cloud bursting is attractive. A hybrid cloud model in which workloads move seamlessly across clouds and dynamically adjust to changing demand serves as a shining example of how IT can enable the business to respond to its customers. However, the reality is that bursting in-house workloads to exploit the near-limitless resources of a public cloud has been more than a headache; for most organizations, it's unobtainable.
"I do not think it is as prevalent as most people think it is," said Edward Haletky, principal analyst at The Virtualization Practice. "The level of automation required, requires absolute trust in the automation, proper monitoring and control. … Are companies doing this? I'm sure they are, but I only know of really big companies."
Cloud bursting challenges
While the idea of cloud bursting is appealing, there are many complicated problems when extending an in-house application to a public cloud. These challenges can outweigh the benefits of cloud bursting, enough to where it might make more sense to buy a few new servers, said Bob Plankers, a virtualization and cloud architect at a major Midwestern university and TechTarget contributor.
"There can be a lot of latency between the in-house pieces and the public cloud," Plankers said. "A lot of organizations have not sized outbound Internet connectivity for these sorts of things. Latency leads to slow apps and slow apps are what you're trying to avoid in the first place."
What exactly is cloud bursting?
While there's general agreement over the goal of cloud bursting -- handling a temporary increase in computing demand -- many experts and analysts have different opinions on what it entails. Experts agreed that the burst should be a temporary extension of an existing in-house workload to a cloud environment. However, they disagreed over whether the target must be a public cloud (rather than private) and about whether the bursting and drawback processes must be automated. In the end, if you can successfully handle the demand spike, it doesn't matter much what you call the process.
Most traditional enterprise application stacks aren't designed to seamlessly scale into a cloud. Consider a situation in which a business's enterprise resource planning system experiences peak demand as the accounting department works to close the books. IT administrators may consider bursting a new front-end engine to handle the demand, but it would still need to communicate with SAP on the backend, said Keith Townsend, SAP Infrastructure Architect at AbbVie, a pharmaceutical research and development company.
"It doesn't make any sense to put those engines in the cloud when my data exists in my data center," Townsend said. "It'd be easier and cheaper to spin up the VMs in my private data center."
Networking is one of the primary challenges with modern approaches to cloud bursting, but those challenges aren't limited to latency and connectivity speed. Security also gets more complicated when applications span in-house servers and public clouds, Townsend said.
"I can set up a rule in my network Layer 2 firewall that watches traffic between two Web servers, but then when I burst out to the cloud, how is that security enforced and how is it logged?" he said. "What happens if I get audited?"
Even if an IT department can meet infrastructure challenges, cloud bursting still presents massive administrative and business hurdles. In many ways, you're adding complexity along with the extra capacity, Haletky said.
"A lot of people talk a good story, but I don't know of many people [bursting from a data center to a cloud], because you have to have really good automation," Haletky said. "How many companies have that level of automation? Netflix does, but are all companies a Netflix?"
Bursting must be planned well in advance, because VM images and data need to be pre-staged in the cloud so that they're ready to take over when an application experiences peak demand. This isn't an insurmountable problem for businesses that can predict future needs, but administrators must make difficult decisions about how much cloud capacity they'll need and how much they're willing to pay to keep data at the ready.
Ironically, one of the motivations for bursting workloads to the cloud -- the desire to avoid capital outlay and contain costs -- can end up backfiring.
"If I automate something, the cost may actually go up if I don't also automate the shutdown of that workload," Haletky said. "The whole idea behind the bursting of workloads is to run what you need when you need it and then fall back to the default. If I fire up 20 new Web servers on Amazon running full bore, that's a significant amount of money every hour."
Planning for volatile apps
The simplest solution -- and often the cheapest -- to dealing with a spike in computing demand is still the traditional method of keeping enough spare server capacity on hand, experts said. This doesn't have to mean buying new servers. The first step to evaluating whether a burst to the cloud is the right approach is to evaluate how you're using your current resources, Townsend said.
"In many cases, the conversation is no longer to burst up to the cloud, but looking at how enterprises are extremely inefficient," Townsend said. "Let's measure the resources you use, and right-size the resources so that you do have the capacity to do these things."
For organizations that experience larger demand swings or have truly run out of capacity, automation tools such as Puppet and Chef, coupled with virtualization and cloud management platforms, can help them build a flexible hybrid cloud approach. However, there are newer vendors aiming to take a unique approach to reducing the complexity of bursting to the cloud.
Ravello Systems allows organizations to map application dependencies, manage network configurations and then clone entire application stacks to the cloud. However, rather than cloning and bursting production applications into a public cloud, most customers prefer to take a different approach, said Shruti Bhat, director of product marketing at Ravello.
"What we're seeing our customers do is keep their production application in their data center and make enough room for it to scale by moving its pre-production copy, its dev and test copy and other environments out to the public cloud," Bhat said. "This is still cloud bursting, but you now take away the performance problems and risk of connecting the application across a VPN and having your data residing somewhere else."
Ravello's customers include an online gaming company, 888poker,that moved QA and certification environments to the public cloud, as well as two major banks that use the product to clone environments for cyber-security labs. Red Hat also uses Ravello's product to offer multi-server lab environments to students in its OpenStack training courses after in-house capacity is reached, Bhat said."Red Hat discovered that every time a student came in, they needed a full-blown OpenStack environment to play with," Bhat said. "If you want to give each student five to six servers, you run out of capacity in your data center very quickly.". "So, as students sign up, they give them access to servers in the data center, and when they run out of capacity they start provisioning these OpenStack environments on top of Ravello."
Israel-based startup Velostrata hopes to help businesses burst in-house workloads to Amazon Web Services (AWS) on demand and looks to address data transfer latency and compliance problems by decoupling compute from the data.. "It takes a long time to move data to the cloud, and exposes that data to security or compliance risks," said Issy Ben-Shaul, Velostrata CEO. "We provide a technology that can move VM images to the cloud and give those images access to on-premises data without degrading performance."
The company's product, which should be generally available product this year, includes a vCenter plug-in, adapts VM images to run on AWS, and streams the VM image to the cloud. This streaming allows the VM to start very quickly, similarly to a streaming video that begins playing before it's been entirely downloaded, Ben-Shaul said. A virtual appliance running in AWS serves as the storage target for the VM, provides deduplication functions and caches hot data.
"We only stream what is needed. In a matter for three to five minutes, you can take a VM that was running on premise and have it up in the cloud," Ben-Shaul said.
Still, while new tools are emerging to streamline and manage on-demand bursting of applications to a public cloud, it's possible that the practice may never become widespread, analysts said. Cloud bursting is as much an application design problem as it is an infrastructure delivery problem. Bursting traditional applications will always present technical and administrative challenges. More enterprise application vendors are offering software as a Service options. And, as more companies invest in public clouds, they may find it easier to build applications for the cloud that are designed to scale out from the get-go, rather than bursting from in-house servers.