An important prerequisite for a full cloud broker model is the technical capability of cloud bursting:

Cloud bursting is the dynamic relocation of workloads from private environments to cloud providers and vice versa. A workload can represent IT infrastructure or end-to-end business processes.

The initial meaning of cloud bursting was relatively simple. Consider this scenario: An enterprise with traditional, non-cloud infrastructure is running out of infrastructure and temporarily gets additional compute power from a cloud service provider. Many enterprises have now established private clouds, and cloud bursting fits even better here, with dynamic workload relocation between private clouds, public clouds, and the more private provider models in the middle; Forrester calls these virtual private clouds. The private cloud is literally bursting into the next cloud level at peak times.

An essential step before leveraging cloud bursting is properly classifying workloads. This involves describing the most public cloud level possible, based on technical restrictions and data privacy needs (including compliance concerns). A conservative enterprise could structure their workloads into three classes of cloud:

• Productive workloads of back-office data and processes, such as financial applications or customer-related transactions:These need to remain on-premises. An example is the trading system of an investment bank.
• Productive workloads of front-office data and processes, such as customer relationship management (CRM): These could go to a cloud provider with high privacy levels. The more local providers of virtual private clouds can offer a CRM system that’s “secure enough” even for an investment bank.
• Development, test, and simulation environments, which contain no customer data and are not subject to compliance regulations.Thus, they can operate on any infrastructure. Examples include even compute-intense forecasting jobs in most cases.

Today’s mainstream cloud consumption model basically maps these different classes of workloads based on static sourcing to the private (cloud) environment, a public cloud, or a virtual private cloud provider. In contrast, the concept of cloud bursting assumes that the private infrastructure is turned into a private cloud, and other workloads can use spare capacity dynamically. Additionally, some service providers for virtual private clouds are actually operating traditional IT manged services at the same time. Spare capacity of a client's managed server can contribute to this client's bursting capacity in the same way than private spare capacity. The savings are obvious, if you compare the static sourcing (above) and the dynamic sourcing (below) in this figure. Both cases represent exactly the same abstract performance requirement per workload class:

Cloud bursting’s workload relocation doesn’t work well for all workloads. For example:

• Video rendering works in the cloud, but interactive editing does not.
• Business process management requires some architectural tweaks.
• Compute-intense workloads work well, but only if they are not talking to an on-premise database all time.
• Network latency to cloud providers can be an issue.

Cloud bursting itself is a technical capability of modern IT management stacks. However, the proper workload classification is an enterprise architecture exercise similar to the SOA service design required in the past decade with the SOA paradigm. Finally, the savings potential of cloud bursting compared with static cloud sourcing will fuel the emerging cloud broker business model during the coming decade.

Let me know if you support or plan to support cloud bursting in your tool offering.

Stefan