从历史上看，企业技术弹性植根于数据中心、托管设施以及经典的托管服务提供商（MSP）。业务连续性管理（BCM）和灾难恢复（DR）的最佳实践通常是由企业IT组织、第三方供应商和灾难恢复解决方案的组合在企业数据中心、托管中心和托管服务提供商（MSP）设施中实现的。
然而，尽管用于灾难恢复的数据中心和传统基础设施方法已成为常态，但针对核心基础设施和数据的供应商无关服务的发展正在催生将显著提高运维弹性的云原生模型。
随着公共云采用率的提高，备份和弹性模型的低成本、低风险解决方案的使用率显著提高。在过去的几年中，一些应用程序的云原生弹性能力甚至“诞生于云端”。然而，一直以来，利用真正的混合和多云作为一种运维弹性机制是不可能的，此外，云服务提供商（CSP）缺乏可用的工具来减少实现的摩擦。现在，企业云客户将采用多云作为一项战略要务，而CSP提供的功能使这一梦想成为现实。
云原生弹性通过以下功能改进了传统弹性模型：
提供统一的模板和构建块：如果你看一下构建弹性的关键组件，所有这些组件都是云原生的，其中许多是标准的、商业化的云服务，用于设计上具有弹性的生产运维（例如，用于防止故障事件的AWSAutoScaling；用于支持关键工作负载的基于网络的弹性能力和工作负载分配的AWSDirectConnect/ELB；用于长期数据保留和存储的EBS/S3/Glacier）。
自动化整个生命周期以包括故障恢复：从备份过程本身的自动化，到预防性措施（如水平扩展），再到故障转移触发的操作处理程序，云原生弹性功能增强了实施和故障转移模型的自动化。
使用“运维工具”而不是“备份工具”：针对多云的新CSP原生产品，即GCPAnthos，大大减少了与多云部署的摩擦，这最终将减少跨CSP部署和新弹性模型的进入壁垒。
可以选择哪些部署模型？
在启用云服务提供商（CSP）的弹性方法时，有三个关键的弹性模型：
图1：云原生弹性模型的范围涵盖了单云到多云选项。
主动-被动配置中的单CSP。这是最常见的弹性模型，对于遗留应用程序，通常涉及单个CSP——该CSP通常充当本地数据中心环境中生产应用程序的故障转移站点。
在云原生模型中，通常对于在云中生成的应用程序来说，这也是最流行的弹性模型，适用于能够容忍某些恢复时间目标（RTO）的应用程序，这些目标不需要主动复制模型。这里的主要模型包括热备用、指示灯和备份与恢复。
在热备用模式中，应用程序的所有基本服务都以最低可行的方式运行，几乎是在完整生产环境的“ProductionLite”版本中运行。在发生故障或其他触发恢复的场景时，可以轻松地扩展此备用环境以处理生产负载，并且可以有效地切换网络更改以将所有流量路由到热备用环境。
在Pilot-Light模型中，来自生产应用程序的数据被复制，应用程序环境被存储为一个模板，在出现恢复场景时可以启动该模板。恢复到正常生产的时间比热备用时间长，但是如果应用程序对停机时间有相对较高的容忍度，那么这也是一种非常经济高效的恢复方法。
最后，许多企业云客户使用CSP（如AWS的备份和恢复、S3Glacier）实现了基本的存储和归档模型，以实现低成本、长期保留企业内部工作负载中的数据。这是早期采用公共云的第一个可行用例之一。
评估和关键注意事项：当执行故障事件的时间从几分钟到几小时是可以容忍的时候，此模型通常是一种标准的、可靠的恢复方法。
主动-主动配置中的单CSP。在AWS配置中也称为多站点，任务关键型应用程序通常需要跨可用性区（AZ）或在某些情况下跨可用性区域（AR）的主动-主动故障切换，具体取决于关键性、区域外恢复（OOR）的合规要求和延迟容限。
通常，此模型的特点是具有主动-主动配置的单个CSP；在AWS中，此模型称为多站点模型，在区域内或OOR中运行相同的生产工作负载，并在DNS中建立网络流量切换和规则。恢复点目标（RPO）通常指定为最后一次异步或同步数据库写入。一些客户已经尝试在AWS美国东西部地区使用多区域主动-主动设计模式来设计他们的DR。
评估和关键注意事项：如果你有非常关键的任务、对时间敏感的、超低延迟的生产应用程序，而这些应用程序“毫秒会产生百万美元的影响”，那么这通常是合适的弹性模型。通常，具有极低延迟和对延迟敏感的应用程序的应用程序可以选择区域内模型，甚至可以选择具有多区域数据中心和云部署的全局部署，以使数据更接近边缘和用户。
主动-被动或主动-主动配置中的多CSP。此模型类似于主动-主动配置中的单CSP，不同之处在于跨AZ或跨AR场景被不同的CSP供应商区域替换。对于每个CSP，这可以在同一区域（例如AWSUSEast-NorthernVa和GCPUS-East-a/b/c），也可以跨不同CSP生态系统的区域。
评估和关键注意事项：在健壮、成熟的CSP工具和服务产品出现之前，许多组织3-5年前就尝试过这种模式。在现代应用程序构建中，使用多CSP通常是为需要进行多云部署的用例保留的（例如，某些CSP跨区域的可用性限制，降低了单CSP供应商依赖的风险）。然而，每个组织都尝试使用自己的定制解决方案，因为这些方案发生在GCP等多云工具出现之前。对于出于技术考虑需要进行全球部署的跨国公司和全球组织，以及为不同国家/地区的客户提供服务的跨国公司和全球组织来说，这也是一个极好的选择，因为这些国家/地区对数据的使用有不同的法律和管理规定。
为什么以前不可能这样做，而现在可以了？
多年前，许多组织曾尝试实现多云架构和运维模式，但都失败了。然而，许多其他原因阻碍了多云的采用，包括：
缺少可用的工具。如今，采用多云与基于容器的产品、编排工具之间的摩擦大大降低，每个CSP现在都提供服务和工具，以促进更开放和模块化的生态系统。许多组织尝试了多云，但都失败了，并回滚到混合云模型，甚至“多个云”模型，在这些模型中，不同的环境是分开管理的。事实上，许多大型金融机构都试图实施自主开发的跨CSP模式，以降低单一供应商环境的风险，最终又回到了混合云模式，而没有强大、成熟的CSP产品的支持来实现同样的目标。
在企业规模上，多云有着高不可及的人才和技能要求。当时，CSP的发展非常迅速，如果没有合适的企业人才模式和技能，就很难完全依靠一个CSP，更不用说多个供应商了。现在，大多数组织在多个CSP基础设施和SaaS环境中运行，并且拥有构建和运行云本地生态系统所需的更多技能，尽管这仍然是一个持续的挑战。
投入产出比低。由于缺乏工具，许多组织尝试的定制解决方案证明，弹性、灾难恢复规划和工作负载移动性带来的好处被全栈成本和维护开销以及与定制解决方案的跨环境相互依赖性所抵消。
服务和工具成熟度如何实现云原生弹性？
三大CSP中的每一家都开发并发布了混合和多云服务，这些服务通过多云运维模式和运维弹性的新方法开辟了一个新世界：
图2：每个CSP供应商都维护一组向多云发展的服务，支持新的弹性模型。
谷歌云平台（GCP）。GCPAnthos于年首次推出，最初是作为一种混合云解决方案，通常被认为是在支持多云模型的扩展中首先上市的。根据Anthos文档，该堆栈旨在与环境无关，但目前主要用于在AWS和VMware基础设施上的本地Anthos集群上运行。向多云的战略转变极大地打开了跨供应商和客户服务提供商弹性模型在模型上的开口，寻求实现相同功能的CSP创造了许多快速追随产品。
MicrosoftAzure。始于AzurePrivateStack的发布，微软很早就开始了推进混合云趋势，在微软生态系统一致性模型中实现了混合云。从那时起，该产品扩展到Azure混合和多云解决方案，其中包括用于实现单一控制平面跨环境的AzureArc、用于将工作负载扩展到边缘的AzureIoT，以及支撑多云生态系统的众多支持服务（如安全、数据、身份、网络）。
AWS。多年来，AWS主要是公共云原生的，并最终演变成混合云（提供AWSOutposts服务）。最近发布的公告显示，AWS原生容器服务将扩展到支持多种环境，甚至支持其他CSP供应商。目前还不清楚AmazonECS-Anywhere和EKS-Anywhere是否能提供与Azure和GCP产品集一样高的支持多云的程度。然而，这是朝着同样的方向迈出的一大步，许多客户有多云支持的需求，并希望最终实现跨CSP的容器可移植性，以提高采用多云模式的弹性。
应该采取什么行动来启用和改进云原生弹性？
行动1：为企业技术生态系统选择合适的云原生“锚”，并围绕其构建弹性模型。
对于许多组织来说，这仍然是关键业务和企业工作负载和服务（如身份、加密和密钥管理）的企业数据中心，然后扩展或联合到公共云环境。对于其他初创企业、数字化和云原生企业，公共CSP生态系统通常是新领域，支持任务和业务关键型工作负载以及企业IT服务。
当选择锚定在公共云中时，灾难恢复并不一定更容易。随着云基础设施资源更易获得，许多公司都已安装了灾难恢复基础设施并准备就绪（例如，热故障切换、指示灯模型）。然而，许多组织并不在多CSP或数据中心环境中实践云原生业务连续性/灾难恢复（BC/DR）或替代模型。BC/DR应该是重中之重，并支持云产品设计、工程设计和实现自动化恢复过程是保护业务不受计划外事件影响的最佳投资之一。自动化减少了DR测试的犹豫，降低了风险，增加了测试的频率。混沌工程经常作为一种测试弹性的技术出现，但我们还没有看到这种技术在大技术公司之外的实践中得到应用。
了解每个模型的关键风险领域以及如何减轻这些风险也很重要，例如延迟、数据驻留和安全策略。数据中心和云区域的物理邻近性、混合和多云工具的数据驻留和加密含义，以及它们的安全协调，这些都常常是许多组织的障碍。
行动2：了解什么是跨CSP供应商服务的商品化，什么是差异化的，以及它如何影响弹性规划。
在设计任务关键型系统时，不仅要考虑功能，还要根据服务选择和架构对弹性的影响进行审查。应考虑两个关键因素：
CSP原生服务选择：应该为内部CSP选择哪些服务，它们的默认故障转移配置文件是什么？如果供应商还需要额外的设计，则必须内置适当的弹性。需要注意的是，本着共享责任模型和良好架构框架的云最佳实践精神，CSP供应商有责任遵守SLA性能承诺，包括服务正常运行时间和持久性。此外，客户必须了解这些服务的架构、使用和配置每个服务的故障转移和恢复模型，以及它如何支持系统故障转移需求所需的更广泛的应用程序架构（例如，主动-主动、主动-被动、指示灯）。
跨CSP或环境选择：哪些服务（或整个应用程序/数据集）应作为跨CSP或环境故障转移的候选服务。如果CSP原生服务选择不能满足你的应用程序架构的所有需求，请考虑对跨CSP供应商环境和工具的选择，以及混合安排中的企业数据中心。
行动3：做出平衡的云架构选择，最大限度地控制同时利用云弹性的好处。
云原生和云不可知的工具和服务都将是必不可少的。随着CSP的发展，商业和公共部门组织现在有了成功的工具。
从对CSP不可知论、控制和工作负载可移植性的极度渴望，到一个或多个CSP供应商及其环境必须提供的一切，都有一个连续的采用范围。我们的建议是仔细评估每一种采用模式相对于更广泛的技术战略的态势，并使平衡的云架构和CSP服务选择成为你的环境和解决方案战略远景的基础。
许多组织“偶然”而不是通过深思熟虑，建立了混合或多云生态系统，并正在经历了解其当前数据中心和云足迹的过程，以评估最佳运维弹性模型以及其他业务需求。选择涵盖了完全云原生、CSP嵌入的生态系统以及云不可知的解决方案。每种模型都可以完全支持混合和多云架构，但在供应商参与度以及工具和服务选择方面有所不同。
观察显示，每种架构模型都有各种各样的采用模式，并有各自的技术和运维权衡。云不可知模型通常采用定制的灾难恢复解决方案跨CSP和数据中心进行设计，同时在IaaS堆栈中大量使用公共云服务，通常需要开放标准和可驻留在任何云环境中的供应商不可知平台工具。
数据系统的恢复是复杂的。在考虑云服务及其弹性时，请