buchachon - Fotolia
Cloud bursting has received a lot of attention over the past few years as a use case that would motivate companies to make greater use of the cloud, thereby fueling the growth of cloud computing. However, the hype has been far out in front of reality.
The cloud bursting approach delivers the extra cycles compute-intensive applications need to handle the spikes in demand that go beyond the compute capacity available in the datacenter or private cloud in which the applications primarily run.
Customers using this application deployment model only pay for incremental compute resources when they are needed. Originally, this was thought to be a potential benefit to companies in industries such as retail or hospitality that experience cyclical or seasonal demand. But it turns out that cloud bursting only makes sense for a narrow range of environments and workloads. The following requirements will help you to decide whether applications running in a hybrid cloud deployment are suitable for cloud bursting.
1. The on-premises data center or private cloud environment must be compatible with the public cloud environment to which applications will burst. This means that any part of the infrastructure an application relies on, usually including server virtualization, storage and networking components, must be fully compatible. While this is certainly feasible, it may not be practical for companies that run different types of workloads in their hybrid cloud and/or want the flexibility to take advantage of multiple public clouds.
2. Applications and data with security, privacy or compliance requirements are not good candidates for cloud bursting. Any public cloud that workloads might run in must support these security and compliance needs. For example, if an e-commerce application that handles customer purchase transactions requires PCI-DSS compliance, any public cloud in which it runs must meet that compliance standard.
3. Storage-intensive applications are not a good fit for cloud bursting. This is because they require users to move storage back and forth between the cloud. The network bandwidth and public cloud storage costs to accomplish this are not trivial, and can easily outweigh the benefits of temporary, on-demand compute capacity. Similarly, any application that relies significantly on a database is probably not well suited to cloud bursting. The cost and effort to synchronize data between on-site and public cloud environments is just too high.
4. State management is challenging. This applies to users that want to run legacy applications on different Web or application servers both on-site and in the cloud, or that depend on ancillary applications in both locations. For example, if an application is running on a web server in the cloud and is using a stateless HTTP protocol to communicate with the same application running on-site, then that application must manage the "state" to ensure consistency of data and user interaction between the two environments.
Non-critical, compute-intensive apps are suited to bursting
Applications that are most suitable for cloud bursting are standalone, non-critical, compute-intensive workloads, which don’t rely on networked storage or need to interact too much with other applications. Examples include seismic simulation (in oil and gas industry), computational fluid dynamics and molecular modeling. These compute-intensive applications are in the sweet spot for cloud bursting, since in most cases they are not dependent on other applications and may not require storage and networking compatibility between on-site and public clouds.
Another scenario in which cloud bursting often makes sense is when a company wants to send a non-critical application to run temporarily in a public cloud to free up local resources for business-critical applications. This "load balancing" use case is especially useful for companies that can anticipate peak demands for critical applications. One example of an offering that facilitates this form of cloud bursting is Unitrends Boomerang. Boomerang users can move a subset of their VMware workloads temporarily to Amazon AWS to handle peak loads locally, and then copy those workloads back to their VMware vSphere environment once peak operating demands have subsided. For instance, if an accounting firm anticipates the need for additional compute resources during tax season, they can run their accounting/tax applications on site and burst non-critical workloads temporarily to AWS.
Though the potential applications for cloud bursting today are rather limited, we believe they will expand in the future. Vendors such as Microsoft are developing technical frameworks and best practices to facilitate cloud bursting, in this case between on-site Windows environments and an Azure public cloud. Cloud interoperability standards may also help, such as IEEE Intercloud. But in the meantime, with the exception of the load balancing scenario outlined above, most users are better off choosing whether to run their workloads entirely on-site or in a public cloud.
Google makes minimal public cloud announcements in 2014
AWS bests the competition in 2014 with cloud offerings