云爆发并未像有些人期望的那样取得成功，但是很多企业仍然渴望使用这种混合云架构。对于那些不惧潜在挑战的企业，需要考虑几个关键因素。

大多数企业使用公共和私有云基础结构来托管其应用程序。一项调查发现，85%的IT领导者认为混合云是理想的运营环境，而半数的人表示混合云可以满足他们的所有需求。

然而，“混合云”的术语涵盖了各种各样的场景，从简单的被动灾难恢复(DR)环境到复杂的冗余主动-主动应用程序。后者(同时处于活动状态和负载平衡的公共云和私有云环境)曾经被认为是理想的云运营模型，因为它使系统架构师能够充分利用两者的优势并最大程度地减少两者的弊端。

云爆发挑战

“云爆发”成为描述这种两全其美方案的术语。在此模型中，私有云基础架构可处理基线资源需求，并托管敏感的旧数据库和后端系统。而公共云基础架构则解决季节性负载高峰、临时爆发和横向扩展Web前端系统的问题。

云爆发的宏伟愿景甚至扩展到成本优化。在称为“多云套利”的概念中，企业利用多个IaaS提供商，以及实时成本分析软件，并在特定时间针对特定工作负载将突发定向到最便宜的供应商。

在什么情况下，云爆发挑战值得企业付出努力

云爆发需要大量的设计专业知识和部署规划。是否值得付出努力取决于每个工作负载的独特特征以及应用程序的业务价值。

突发模式非常适合那些容量需求发生极大变化的创收应用程序。在这种情况下，本地系统可以满足基线资源需求，而低成本、基于云的竞价型实例可以在需求激增时为这些系统提供支持。

不幸的是，就像通常的情况一样，这种“优雅”的理论面临着多云基础设施和应用程序设计混乱的现实。其结果是，即使有更多公司希望部署云爆发架构，但很少有公司真正能够部署。的确，持怀疑态度的人认为云爆发在很大程度上只是一个神话。咨询公司Architecting IT最近指出了通常阻碍部署的4个重大挑战：

• 网络，即在公共云和私有云之间建立低延迟、高带宽、冗余连接，并自动将传入的连接路由到最佳位置;
• 安全，这涉及跨多个环境为用户和系统部署一致的策略和控制;
• 数据一致性，或者说在多个站点同步数据存储的问题，特别是在高事务负载期间。
• 数据保护，这是从多个来源提供备份时保持备份一致性的相关问题。

我要添加第五个挑战：自动部署和动态扩展资源。这与公共云(主要是计算或容器实例、但也有存储I / O)处理瞬态突发需求的能力有关。

这些都是可解决但很复杂的问题，这使得很多企业得出结论，云爆发不值得付出努力，至少需要他们拥有可跨多个云运行的新一代分布式应用程序模型。对于那些仍然不为所动的企业，下面是解决每个云爆发挑战的方法。

网络和安全

网络和安全性是最基本的云爆发挑战，因为无论是否使用云爆发，任何混合环境都必须解决这两个挑战。幸运的是，IT团队可在这个领域获取最广泛的技术和服务，包括来自主要云提供商、电信公司、ISP和托管服务商的技术和服务。现在有多种安全方式可以链接私有云和公共云，以改善混合云的连接性：

• 虚拟专用云，使用标准VPN协议(通常为IPsec)以及虚拟路由器将本地网络链接到公共云中的一个或多个私有子网。企业可以通过VPN将其公司网络扩展到云子网中，并通过合并虚拟服务(例如路由器、NAT网关和Internet网关)来保持对流量的完全控制。
• 专用电路–使用云提供商的服务(例如来自谷歌、甲骨文和IBM的AWS Direct Connect、Azure ExpressRouteor产品)。这些产品可在客户的私有云和公共云网络之间提供专用的低延迟的链接。由于端点位置的限制，服务通常终止在托管中心，该托管中心可以将其连接到客户的专用机架而不是公司数据中心。
• 专用电路—使用电信公司、ISP或托管提供商的服务。这些类似于云提供商提供的服务，但是它们利用与主要运营商的广泛互连来提供更多终端位置。AT&T NetBond或Equinix Cloud Exchange等服务还简化了多云互连的设计，因为它们与所有主要的IaaS和SaaS提供商对接。

这两种类型的专用电路服务都使企业能够完全控制网络路由、流量管理和安全策略。但是，Direct Connect等云提供商服务是克服云爆发挑战的最佳选择。这些服务依赖终止于云提供商数据中心的光纤电路，因此它们提供了最高的性能和最低的延迟。

数据一致性和保护

与云灾难恢复部署类似，云爆发需要将应用程序组件从本地复制到公共云IaaS。除非企业已经完全部署与云无关的基础架构即代码系统(例如Terraform、Chef、Ansible或其他允许以编程方式实例化资源和配置的系统)，否则企业必须手动构建必要的基础结构资源和网络拓扑。当部署到位后，云提供商的本机工具(例如AWS CloudFormation或Google Cloud Deployment Manager)就可以自动扩展或复制其他云区域中的资源。

企业可以多种方式解决数据同步问题，具体取决于应用程序架构：

• 将数据库留在本地，并通过上述专用电路确保可靠的高速混合云连接。该策略适用于对延迟不敏感且不会持续访问数据库的应用程序，因为前端和业务逻辑应用程序层是负载增加时的主要瓶颈。
• 跨位置复制数据库，特别是对于具有大量事务数据库负载的应用程序。复制从本质上引发了数据一致性问题，但是这些问题已经由支持多站点复制的数据库系统(例如Oracle和Microsoft SQL Server)解决。那些需要实时一致性的应用程序必须使用更复杂的方法，例如Oracle RAC、GoldenGate或各种第三方或开源产品(例如Qlik Replicate或SymmetricDS)。

动态资源分配

当建立网络管道和应用程序基础架构后，云爆发的操作部分包括在本地和云环境之间动态地定向和平衡工作负载。

这里涉及的主要工具是负载平衡器、应用程序交付控制器和虚拟网络接口。现代负载均衡器具有足够的配置选项，用于指定负载加权因子、资源/ CPU限制和备用配置，以适应任何突发情况。AWS Elastic Load Balancing、Google Cloud Load Balancer或Azure Load Balancer等云负载平衡服务会自动扩展容量以处理增加的流量。

云爆发的另一个挑战是动态容量管理。容器化应用程序在这里具有固有的优势，因为Kubernetes可以自动扩展群集和Pod，这是主机上的容器组。所有主要的云Kubernetes服务都包括集群自动扩展。

对于VM托管应用程序，容量管理更为棘手，尽管主要的云平台确实支持通过EC2 Auto Scaling和Azure Scale Set等服务对实例组进行自动扩展。这些工具会响应相应的监视服务中的策略，例如虚拟CPU利用率、网络流量或其他指标。