For many digital businesses, the ability to handle huge increases in demand – from the rush to an etailer’s site on Black Friday to the Saturday night stampede for meal delivery services – is key to their ongoing competitiveness.
To cope with the extra burden, these firms often look to divert some of the data processing workload from their own systems to a public cloud service. But the fact that the spikes in demand are temporary means that they won’t need that additional capacity permanently – and they definitely won’t want to pay for it. This is where cloud bursting, an application deployment method first proposed by Jeff Barr, chief evangelist at Amazon Web Services, comes into play.
An adaptation of the hybrid approach, using both public and private clouds, it enables IT teams to set workload thresholds for their own systems and applications. When such a threshold is reached, the cloud bursting configuration will trigger an application to start working in a public cloud, where it can more easily cope with the increase in traffic coming its way.
“Cloud bursting offers evident advantages to businesses in terms of cost, flexibility and service continuity,” says Ravi Mayuram, CTO at cloud database platform Couchbase. “First, you pay only for what capacity you use, avoiding fixed overheads. Second, resourcing can be much more flexible: you scale back once the need goes away. And third, cloud bursting means that applications and services can continue operating during demand peaks (or at other times) without negatively affecting the user experience.”
Although dealing with workload spikes is its main application, cloud bursting can also be utilised for processor-hungry modelling tasks such as 3D rendering, or in software engineering, where running virtual machines can become prohibitively costly. Bursting into a public cloud also gives users access to tech that’s often optimised for big-data analytics and AI tasks.
Where to start with cloud bursting
Sounds attractive, doesn’t it? Especially as there are established container environments that natively handle cloud bursting. But there are some caveats to consider and careful preparation is needed before adopting this approach.
First, a company must look closely at each application to determine whether bursting it would be feasible in its current state. This decision will often boil down to how an application has been designed, notes Steve Judd, senior solutions architect at the Jetstack consultancy.
“The ideal architecture is loosely coupled and independent,” he says. “This means that the components communicating between the private data centre and the public cloud don’t need to transfer large amounts of data between them. They can also tolerate unpredictable latency.”
The three cloud-bursting mechanisms
Once an application’s suitability has been established, the CIO will need to determine the most suitable bursting mechanism for their business. There are three options available with the big cloud service providers.
The first is manual, where an IT administrator must decide when to instigate the burst and then when to bring that workload back. The second is automated, where it’s left to the tech to manage cloud resources and shift workloads around according to the instructions given to it. The third is known as distributed load balancing.
The challenge is to plan for adequate networking bandwidth between private data centres and the public cloud
Judd explains what this involves: “It’s where you have a small capacity of standby servers already provisioned and ready in the cloud. This mitigates the risk of having your own servers overwhelmed when there’s a steep increase in traffic.”
The balancing system will allocate the workload between the two environments and scale up the cloud element automatically whenever a spike in demand occurs.
The manual option is the most accessible of the three approaches and it’s a good way for organisations to test new cloud bursting projects, but it’s also most prone to inefficiency and error, given that it relies on human judgement.
“Automation is key here,” argues Greg Adams, vice-president of Dynatrace’s operation in the UK and Ireland. “The most effective way to support this is by using service-level objectives (SLOs) to set thresholds for what constitutes an acceptable user experience. For instance, SLOs for application response times can enforce an automated process that invokes cloud bursting at the instant the user experience falls below that threshold.”
Mayuram notes that network capacity problems can sometimes stymie a cloud burst because such problems tend not to reveal themselves until it’s too late. If there isn’t enough bandwidth, he says, “then all the goodness of cloud bursting is only a theory; it will never materialise. The challenge is to plan for adequate networking bandwidth between private data centres and the public cloud, so that bursting actually happens effectively and meets your SLOs.”
Security and oversight of cloud bursting
No matter which mechanism a company chooses, security and regulatory compliance must remain a priority when bursting is enabled.
“The kind of data that will be sent has to be monitored and protected carefully,” Mayuram stresses. “If there’s material that’s protected by compliance requirements or any other industry-specific governance standards, organisations need to take adequate precautions to ensure that their security procedures are tight enough to meet these standards.”
To safeguard the data being transferred in bursts, businesses should set up encrypted routes between their systems and the public cloud, Judd advises.
“Also, the dynamic nature of cloud bursting creates an influx of machine identities,” he says. “As such, organisations must deploy a control plane to automate the management of these identities. This gives their teams the observability, consistency and reliability they require to effectively manage their machine identities.”
Ultimately, a firm needs to monitor its use of cloud bursting constantly to check that its performance keeps within the tolerances that have been set for it – and to verify that the method remains cost-effective.
If doubts were to arise on either count – for instance, if the cloud provider were to increase its fees – the CIOs would need to review their workflow models to determine whether their bursting strategy is still viable. Otherwise, it can be all too easy to get caught out in the rain.
For many digital businesses, the ability to handle huge increases in demand – from the rush to an etailer’s site on Black Friday to the Saturday night stampede for meal delivery services – is key to their ongoing competitiveness.
To cope with the extra burden, these firms often look to divert some of the data processing workload from their own systems to a public cloud service. But the fact that the spikes in demand are temporary means that they won’t need that additional capacity permanently – and they definitely won’t want to pay for it. This is where cloud bursting, an application deployment method first proposed by Jeff Barr, chief evangelist at Amazon Web Services, comes into play.
An adaptation of the hybrid approach, using both public and private clouds, it enables IT teams to set workload thresholds for their own systems and applications. When such a threshold is reached, the cloud bursting configuration will trigger an application to start working in a public cloud, where it can more easily cope with the increase in traffic coming its way.
