Cloud bursting: Six key steps in planning and decision-making

1. Scenarios: Modelling data and workflows

Organisations need to start by looking at their current IT estate, including how they use the cloud, their workflows and the data they handle.

Cloud bursting is most often associated with compute rather than storage. That’s because moving large volumes to the cloud and back may not be practical due to costs, latency and risks to data integrity. Firms are more likely to burst workloads to the cloud when data is already there, or where there are bottlenecks in processing data.

There are situations where data can be offloaded to the cloud more permanently, such as for archiving, advanced analytics or artificial intelligence and machine learning. Offloading (often unstructured) data to the cloud is increasingly popular as firms move to object storage. But these are not, strictly, bursting scenarios.

Moving data from relational databases is more difficult for performance reasons. Transactional systems, in particular, are sensitive to latency. On the other hand, a web-based, consumer-facing application could burst to the cloud, as consumers are less likely to be put off by small delays in transaction processing.

Test and development work, though, can more easily be moved to the cloud and can free up resources for production systems.

Chief information officers (CIOs) should therefore assess the suitability and practicality of bursting applications to the cloud – not forgetting to take into account the cost of capacity, and supporting infrastructure such as high-speed interconnects to the cloud provider.

As Ajay Khandelwal, managing director for software strategy at consulting firm EY, notes, there are four key workloads CIOs should assess: Static, periodic, “spiky”, and unknown or temporary. All but static workloads can benefit from bursting if it is done well.

2. Look at bursting mechanisms

The big cloud providers break down bursting into three categories: manual bursting, automated bursting and distributed load balancing.

Manual bursting has the widest compatibility but usually the lowest performance, as someone needs to invoke the burst and also decide when to bring the workload back in house.

Automated systems are more efficient, but require up-front investment in technology, such as scaling technology for virtual machines (VMs) or a move to container platforms, and in IT usage analysis. Without robust data, firms will not know when to burst or how much capacity to move to the cloud.

And, although systems such as distributed load balancing are largely invisible to the user, the IT architecture has to be designed to support it. 

3. Application suitability for bursting

A growing number of applications are now “cloud native” and designed to work in hybrid or multi-cloud environments. But older, enterprise applications are usually not.

Firms need to look at their applications to see if bursting is possible, or whether the application needs to be updated, adapted or even replaced. If it is an in-house application, devops teams will need to be familiar with cloud bursting and its technical requirements.

Some applications will just not suit the process, because they are highly sensitive to latency, or variability in service levels or processing times. These applications might be better running in-house or possibly entirely in the cloud.

This is also the case for applications with very large volumes of data. Moving data into the cloud will take longer than is practical, given the need to maintain application performance.

And organisations also need to consider security, compliance and governance, especially when data is transferred to a public cloud provider.

IT teams should also look at governance. Can they control the bursting period? How long is the excess workload likely to be, and how easy is it to scale down again? Using a cloud bursting mechanism as long-term cloud infrastructure is unlikely to be cost effective. 

4. Analyse resources

Although cloud bursting is now fairly well-established, and something that container environments such as Kubernetes handle natively, setting up applications and data stores to burst to the cloud demands careful preparatory work.

Firms should consider whether they have the budget, skills and time to introduce cloud bursting. And CIOs need to weigh these factors against the alternatives.

These include additional on-premise resources, or more efficient use of them through VMs and more modern architectures such as containers, moving the entire workload into the public cloud, or using a more permanent, hybrid environment. Again, much will depend on the volume, nature and sensitivity of the corporate data. 

5. Build a business case

Once the IT team has audited data, applications and workflows, they can build a business case for cloud bursting. This will be governed by, of course, the costs and on the type of cloud bursting that best suits the workload.

This, then, should be set against the benefits to the business. As Anay Nawathe, a consultant at ISG, points out, bursting is most suited to “compute-intensive and non-critical workloads”, rather than core enterprise systems.

However, there will be other scenarios where the business case is simpler. These are common in sectors such as retail and media and entertainment.

If the marginal cost of the transaction on a “bursted” basis is lower than the sales revenue it brings in, and performance is within the user or customer’s tolerances, it is worth doing. At EY, Khandelwal points to using the cloud to run e-commerce promotions during a sports event or Black Friday where firms have made savings of 50% by moving those workloads to the cloud.

6. Plan and test

Finally, firms need to plan for how to introduce cloud bursting, and test that it works as intended. Organisations need to be sure that not only can they burst to the cloud, but they can scale back down quickly and without impacting application performance.

Nor is this is just about carrying out technical tests, although those are vital. It is also about monitoring consumption, and combining the data with the cloud service provider’s prices to understand the true cost of the process.

And if technology, business needs or CSPs’ prices alter, CIOs should run their models again to go back through this workflow and look once more at their cloud bursting decisions.