如果询问任何一个开发人员或DevOps经理采用公共云上的首次体验，他们很可能会分享一些项目或新应用程序配置一些计算实例的经验。企业可以充分利用全套公共云服务，以及可扩展性，弹性，安全性和即付即用定价模式。所有这一切使企业团队轻松开始使用云计算，节省了IT预算和基础架构设置时间，公共云提供商AWS，微软Azure，谷歌云，Rackspace等使其易于创新。
在未来的几年里，云计算的早期的承诺仍然是相关的：服务的扩展，成本（某些情况下）减少，以及DevOps团队已经通过运行计算实例来适应他们团队的需求。但对于许多公司来说，其混合的IT基础设施的现实需要支持多个公共云提供商的服务为了实现这一目标，IT运营人员需要一个位于其基础设施之上的控制层，并可通过任何架构（包括多云）向客户提供应用程序，而不管其团队支持多云环境的原因是什么。
做好最坏的打算
IT运营人员或者失去访问他们的网络应用程序的人都知道，中断和云服务的退化随时可能发生。现代行动团队需要制定计划。许多公司选择利用多个公共云确保其应用程序始终可供全球客户使用，即使在中断时也是如此。在这种情况下，将流量手动重新路由到第二个公共云的过程是麻烦的。在基础架构之上添加应用交付控制计划，允许企业通过多个云端无缝和自动地交付应用程序，并提供实时可用性和性能。
支持云驱动的创新
运营团队经常支持许多不同的敏捷开发团队，通常在多个国家或新的公司收购中进行。在这种情况下，各种团队很可能在多个公共云上使用许多架构。要求一些开发团队切换云供应商不是很重要的DevOps.一个更好的选择是使用云计算无关的控制平面来控制应用程序传送自动化，这些控制平面位于任何云计算，数据中心或CDN架构之上。这允许开发团队在首选的云环境中工作，而不必担心交付问题。
避免云供应商的锁定
公共云供应商（如AWS或微软Azure）不仅仅是基础设施即服务（IaaS）供应商，他们也销售（或转售）一些竞争力非常强的产品和服务。开始时，使用一些云实例并不那么重要。但现在企业已经全面生产并依赖于其中一个云提供商来完成关键任务应用程序，这就不再是一个伟大的策略了。将第二个公共云添加到企业的基础架构中可以减轻企业对单一云计算供应商的依赖。
多供应商采购在IT的许多其他领域都是行之有效的商业策略，在价格和服务等级协议（SLA）谈判中提供更多的选择。IaaS也是如此。随着新服务被添加或删除，价格结构发生变化，云服务经常发生变化。控制公共云服务产品的这些变化，定价模式和SLA是企业运营团队转向多云架构的另一个强大动力。一个应用交付自动化平台，可以吸收和采取云服务定价数据，这一点至关重要。
应用程序（以及它们如何交付）已经发生了变化现代的分布式应用程序由微服务提供支持。同样，较早期的应用交付控制器（ADC）是为静态基础架构世界而构建的，之前企业通常使用云计算（SaaS）。使用应用交付控制器（ADC）进行应用交付需要大量的前期资本支出，从而限制企业快速扩展并阻碍支持动态（即云）基础架构的灵活性的能力。在多云环境中使用应用交付控制器（ADC）可以将这些问题指数级化。软件定义的应用交付控制层消除了对旧的应用交付控制器（ADC）技术的需求，并直接扩展企业的业务和基础架构。
重新控制
完全支持产品中的多云这可能听起来很难。毕竟，运营团队团队每天都有很多的工作要做。添加第二个云计算需要显著的提升周期才能准备好生产级别的交付，以及新的协议，警报，能力和需要考虑的其他事项。企业不能对每个云平台的细节有毒害深度的掌握，并且仍然管理数据中心基础架构。在多个云上增加应用交付的复杂性可能是一个挑战，但如果企业使用基于SaaS的应用交付平台，则会少得多。因此，使用多云基础设施，控制是关键。