如果你根据某些云功能所产生的总收入或用户总支出来分别对它们进行排名的话，云爆发和故障转移将是这两个排名中的第一名。很多企业认为这两个功能是同等重要的，并发现这两个过程可以互为支持。事实上，混合云部署的最佳策略就是整合云爆发和灾难恢复这两个功能。
当一个应用所要求的工作量超过了它的容量时，就会发生云爆发，或被称为工作量溢出处理。它允许企业在云中启用应用的额外实例，以防止影响用户使用体验质量的情况发生。这是公共云资源如何帮助增加企业内部IT资源的一个完美示例，它避免了数据中心中出现昂贵的产能供过于求的情况，对于企业来说这无疑是极具经济意义和现实意义的。
云爆发需要两个关键的技术要素：首先应用设计应允许多个实例同时运行，其次还要有一个机制用于实现所有实例之间的工作量平衡，——无论他们是在数据中心还是在公共云中运行。
混合云下的云爆发和灾难恢复
在云中，故障转移，或被称为灾难恢复对于用户来说也是非常重要的。很多企业已经在考虑或着已部分实施了备用数据中心以确保他们的应用在发生重大故障、部分或全部常规数据中心资源无法使用的情况下仍能够继续正常运行。
在故障转移策略中，其关注的重点往往是重大事故，例如飓风或整个地理区域的电力供应中断。很多情况下，企业完成主资源至备用资源的迁移是有一个可预计的中断期的。在很多情况下，应用将在一个地方或其他地方继续运行，而传统的机制(例如域名系统(DNS)在发生故障时会把用户的访问重新指向备用数据中心，而当故障排除后则又恢复指向原来的生产主数据中心。
很明显，云爆发代表了一个更灵活的灾难策略方法。如果应用的工作量不断增长就会触发云爆发，那么应用的可用资源减少(例如服务器或者甚至数据中心发生故障)也可触发这个功能。这个灾难恢复策略不仅可以处理整体数据中心故障的情况，也可以应对有限设备、软件或者甚至网络故障这样的突发事件。总而言之，成功的云爆发是构建混合云应用的一个有用的策略。
创建强大的云爆发实施
与资源故障相关的问题，而不是应用工作量的增加，将有助于确定云爆发是否可用于构建混合云应用。用户需要访问一个应用的任何额外副本，而应用副本要求访问数据库和其他资源。这两种可能的情况是否都在灾难恢复模式中使用了云爆发？
用户访问多个应用副本需要某种形式的负载平衡。在大部分的情况下，企业在他们的数据中心在广域网网关和数据中心服务器之间会使用三级路由器、应用交付控制器或者其他类似的设备。然后，这个设备就会根据实际需要在应用的多个副本之间调整工作量。如果支持云爆发，它可在这些内部负载平衡设备“后”连接公共云，那么不仅服务器故障会导致数据中心发生故障，而且工作量平衡设备的故障也有可能造成数据中心发生故障。在这种情况下，将无法访问公共云资源。
反之，创建强大云爆发实施的最好方法是从基于网络的负载平衡策略开始入手。
负载平衡即服务是OpenStack新发布的Grizzly中的一个新功能，这个新功能正越来越多地被云供应商们所使用。有见地的用户们还可以在云中构建这样的应用和主机。使用这个方法，所有的负载平衡都发生在云中，而数据中心应用资源都与云资源链接。这就意味着，数据中心故障并不会导致应用产生连接性的问题。
数据中心或应用访问性的问题则更为复杂。 在工作量触发的云爆发中，我们可以安全地假设，数据中心中的应用数据仍然是可用的，而应用基于云的副本仍然可以访问它们。如果资源故障触发了云爆发——尤其是整个数据中心级别的故障，那么数据中心中的数据库资源是不可用的，而应用的云副本则无法访问数据。
由于成本、安全性以及合规性等方面的原因，将一个公司的整个数据库迁移至云可能是非常不现实的。那么，唯一的选择是提高应用数据库元素的可用性;使用额外的备份电源、冷却设备或者甚至可能在备用场所提供关键应用数据的热备份副本来保护数据存储和查询处理器。虽然这样做肯定会在一定程度上增加成本，但是其费用也几乎肯定比维护一个完整的备用数据中心要少得多。
云爆发和灾难恢复可能需要对应用进行一些优化。联机事务处理可能需要进行多个数据库副本更新以维护一个最新的备用副本。企业可能还需要分析应用工作量以确定可以复制应用的哪些组件以提高应用的整体性能和可用性，并在多个组件同时访问同一个数据库时确定如何维护数据的完整性。
虽然对于经验丰富的架构师来说，这一类型的应用问题并不是新问题，但在云爆发和灾难恢复功能中还需架构师做出针对性的新调整。
甚至有可能一个同时完成云爆发和故障转移的应用需要特别的设计。同杨，测试和审查在实现这些业务目标中也是至关重要的。