Years ago, the notion of hybrid cloud bursting was compelling: How cool is it to have workloads on both private and public clouds and be able to run those workloads on the private cloud during normal operations and burst to the public cloud when resources on the private cloud were running low?

Private clouds are no longer a thing. Although some companies do use them, and private cloud companies still exist, for the most part the growth is occurring in the public cloud. You need a private cloud to burst fro and there just aren;t that many of them.

You need to maintain workloads on both private and public clouds for hybrod cloud bursting to work. Typically, the public and private clouds provide different capabilities and native API sets, and localizing the software for two clouds takes time, costs money, and adds risk.

And the obvious: The bursting hybrid clouds concept just added too much complexity and cost for a technology stack (the cloud) largely adopted to let companies do the most with the least.

By the way, I’m not saying that hybrid cloud bursting does not work; it clearly does. I’ve built a few of those myself, in fact. But it’s just not practical or desirable for most organizations.

Still, there will be some practical uses for the bursting concept, such as Microsoft having built a private cloud platform analog of its public cloud (Stack) and those that have figured out that the best way to burst is to loosely couple traditional on-premises systems to the public clouds, using middleware.

The loosely coupled approach is attractive because you don’t need to replace your on-premises systems with a private cloud; you are simply coupling your on-premises workloads with a public cloud that can take on some of the processing. Use cases include keeping the data in the public cloud but processing it on-premises, or vice versa. In that case, you’re not trying to maintain the same workloads on both places, but separating the workloads by function. That’s why this approach is growing in popularity.