云爆发迁移因其在企业中的应用潜力可能会被炒作一番，但是在迁移至公共云之前用户还有一些因素应予以考虑。
随着一些云爆发迁移技术促使企业更好地利用云的典型案例，云爆发迁移在过去几年的时间中已越来越受到了广泛的关注，从而大力地推动了云的发展。但是，关于这项技术的炒作已经远远超过事实了。
云爆发迁移方法为具有额外计算高峰周期的计算密集型应用程序提供了解决方案以便于当应用之前运行的数据中心或私有云出现可用计算资源低于实际需求的情况时应对应用高峰。
使用这类应用程序部署模式的客户只会在他们有需要时才会为增量计算资源支付费用。最初，这个方法被认为是对诸如零售业或娱乐业等具有周期性或季节性需求企业具有潜在优势的。但是，事实证明云爆发迁移只对一小部分的环境和工作负载才有实际意义。以下几点要求将帮助用户确定运行在混合云部署中的应用程序是否适合使用云爆发迁移。
1. 本地内部数据中心或私有云环境必须与公共云环境都对云爆发迁移应用程序兼容。这就意味着一个应用程序所依赖的基础设施的任何部分（通常包括了服务器虚拟化、存储设施和网络组件等）都必须是完全兼容的。虽然这一点肯定是可行的，但是对于那些在他们的混合云运行不同类型工作负载和/或希望灵活性以便于充分利用多个公共云的企业来说，这一点又是不切实际的。
2. 具有安全性、隐私性或者合规性需求的应用程序和数据都不是云爆发迁移的良好候选应用对象。可能会运行工作负载的任何公共云都必须支持这些安全性和合规性的要求。例如，如果一个处理客户采购交易的电子商务应用程序被要求遵守PCI-DSS合规性，那么运行这一应用程序的任何公共云都必须满足该合规的标准。
3.存储密集型应用程序并不适于使用云爆发迁移。这是因为它们要求用户在云计算之间来回移动存储数据。为实现该目标的网络带宽和公共云存储的费用并不是微不足道的，而且这一成本很容易就会超出临时性按需使用计算容量所带来的好处。类似地，任何显着依赖于数据库的应用程序可能也都不适合云爆发迁移。这是因为在内部平台和公共云环境之间实现数据同步的费用和努力都是太高了。
4. 状态管理是具有挑战性的。这适用于希望在不同网站、或内部平台和云中应用程序服务器上运行原有应用程序、或者在不同位置依赖于辅助应用程序的用户。例如，如果应用程序是在云中的网络服务器上运行的且使用无状态HTTP协议与在内部平台运行的相同应用程序进行通信，那么这个应用程序就必须管理“状态”以便于确保两个环境之间数据与用户交互的一致性。
非关键业务、计算密集型应用程序适于采用云爆发
最适于采用云爆发迁移技术的应用程序是那些独立的、执行非关键业务的、计算密集型工作负载、不依赖于网络存储或者需要与其他应用程序进行高密度交互的应用程序。具体应用实例包括了地震模拟（在石油和天然气行业）、计算流体动力学以及分子建模等。这些计算密集型应用程序都是云爆发迁移技术的发力“甜区”，因为在大多数情况下，它们都不依赖于其它的应用程序，而且可能不需要内部平台和公共云之间的存储与网络的兼容性。
云爆发迁移技术大显身手的另一个应用场景就是，企业需要发送非关键业务应用程序至公共云临时运行以便于为关键业务应用程序腾出足够的本地资源。对于那些为关键应用程序预估出高峰应用需求的企业来说，这一“负载平衡”的用例是特别有用的。使用这一形式云爆发迁移技术的一个产品例子就是Unitrends Boomerang。Boomerang的用户可以临时把他们VMware工作负载的一个子集迁移至亚马逊AWS以便于在本地处理应用高峰期的工作负载，然后一旦高峰运行需求消失时就可以把这些工作负载复制回他们的VMware vSphere环境。举例来说，如果一家会计师事务所预计在报税季期间需要使用额外的计算资源，那么他们就可以在他们的内部平台上运行他们的会计/税务应用程序，而临时性地把非关键工作负载推至AWS中运行。
虽然目前云爆发迁移技术的潜在应用是非常有限的，但是我们有理由相信这一技术有望在不久的将来得到显着的发展。诸如微软公司这样的主流厂商正在开发技术框架和最佳实践以推动云爆发迁移技术的发展，即实现在组织内部windows环境和Azure公共云之间的云爆发迁移。这里，云互操作性标准可能会有所帮助，例如IEEE Intercloud。但是与此同时，除了上述所述的负载平衡应用场景以外，大多数的用户最好还是选择是否完全在组织内部平台或在公共云中运行他们的工作负载。 |
