作者：柯善学
不知云，焉知云安全。
本文是Gartner《2020年规划指南》的十个分报告之一，介绍了企业上云的规划趋势。云已经成为企业转型和获得竞争优势的基础，云将继续作为数字业务所需的创新平台。企业应确保云成为组织中的主流计算平台，并将其混合云和多云战略扩展到边缘。
同系列相关阅读
图1-《Gartner规划指南》十大领域（分报告）
其中，云计算的主要技术规划趋势和重要规划考虑如下图所示：
图2-2020云计算关键规划考虑因素
组织将制定一个全面的多云、边缘和场内战略
我们将分别对图中四大趋势及其规划考虑作进一步描述。考虑到该报告太长，计划分为几篇分别介绍。本次介绍其中第一项：组织将制定一个全面的多云、边缘和场内战略。
本文给出了公有云采用框架，解释了边缘计算和云的关系，边缘计算和分布式云的关系，边缘计算和物联网的关系，还谈到了对供应商锁定的见解。值得一读。
一、组织将制定一个全面的多云、边缘和场内战略
2020年，随着互联网的可执行性，各组织将继续加速数字业务时代的步伐。一个安全、分散的分布式网络和应用世界将迎来机遇时代。未来几年，预计将有30多亿新客户首次进入商业生命周期。
据Gartner估计，到2021年，将有超过250亿个连接的传感器和端点。
亚马逊、OneWeb和SpaceX等公司正在发射数千颗卫星，将互联网连接到世界各地。今天，全球约80亿人口中有58%的人连接到互联网。数十亿新客户和设备的增加，将颠覆每一个行业和供应链。此外，随着5G连接性、人工智能/机器学习（AI/ML）、区块链、物联网（IoT）、边缘和持续的云创新等技术，永远改变了技术格局，企业正经历着一场IT复兴。在2019年的Gartner技术专业人士调查中，客户报告说，由于变化的速度很快，技术的多样性，他们越来越难以做出架构决策。
为了应对这场动态和颠覆性的格局，组织必须制定一个整体的多云、边缘和场内战略，足以灵活以快速适应变化的步伐。组织还必须计划对技能集、跨业务的供应商知识以及云管理和治理专业知识的投资。
二、规划考虑因素
1、制定一致的多云和混合云战略
云计划经常会被内部政治因素耽搁，一些企业内部人士不愿放弃自己的控制权。组织的其他人员可能认为，通过使用内部资源，他们可以更好地构建和保护应用程序。然而，大多数组织无法与云供应商的创新速度和规模经济相竞争。大多数云供应商都在这个速度更快、成本更低的基础设施上开发增值服务，实现了大规模的自动化和商品硬件的标准化。在公有云计算领域的创新速度是最快的，反应更快的竞争对手往往会在市场中获胜。
云项目之所以复杂，主要有两个原因：
■组织通常有多个项目以不同的速度执行。一个团队可能正在选择供应商和开发架构，而另一个团队可能刚刚起步。根据组织的规模，这些团队之间甚至可能不知道彼此的计划。
■许多人需要参与云计划，以确保实现适当的架构。许多遗留IT运营工具和流程不容易扩展到云，因此需要新的工具执行监视、配置、故障排除、备份和其他传统流程。然而，组织通常是在云团队和所需技能完全准备好之前就已经开始了这些计划。
克服这些云实现问题，需要一个健全的过程。开发这个过程的起点是Gartner的“实现公有云采用框架的解决方案路径”，它提供了一个高层次的云采用框架（见图3）。
图3-实现公有云采用框架
此框架可用于确定成功实施云计划所需的投资和步骤。然而，即便是使用采用框架的组织，也必须意识到公有云市场的快速发展趋势，并相应地进行调整。有关详细信息，请参阅“设计云策略文档”。
2、评估分布式云和边缘选项
在过去的几十年中，计算在分布式和集中式架构之间摇摆了很多次。云计算，从终极来看，是集中式的，而边缘代表了向分布式拓扑的转变（下一章将讨论边缘）。“分布式云”最终实现了钟摆位于中间的平衡，即集中式计算和分布式计算相互完成。分布式云通过将云服务扩展到更多的位置，来增强和改进核心云组件和服务。Gartner对分布式云的定义如下：
在分布式云中，公有云服务（包括必要的硬件和软件）分散到不同的物理位置（即边缘），而服务的所有权、运营、治理、更新和演进仍由原始公有云供应商负责。
迁移到分布式云模型，可以增强许多计算方面，包括性能、法规遵从性、风险降低和可靠性。重要的是，云计算的核心租户——“即服务”（as-a-service）的消费模式——坚持使用分布式云模式。尽管基础设施本身位于经典的公有云区域之外，但供应商仍然负责大部分服务的交付和维护。分布式云组件不一定非要一直连接到中央公有云服务。但是，公有云控制平面必须扩展到所有分布式云组件，因此在某些点上的连接性是需要的。这种模型的例子包括AWS Outposts和Microsoft Azure Stack。
有些人可能会问，“这不就是边缘计算的情况吗？”根据上下文的不同，这里的答案可以是“是”或“否”。分布式云的所有实例也是边缘计算的实例。然而，并不是所有边缘计算的实例都是分布式云。
实际上，分布式云将在两个不同的阶段发展（见图4）：
1.同类混合：企业客户将购买云变电站，以兑现混合云的承诺，并避免基于延迟的问题，同时保留云价值主张。这些客户最初不会接受向附近邻居开放变电站的想法。他们将把变电站保留在自己的地盘，仅对自己开放使用。通过让公有云供应商承担一切责任，这种方法将产生“拯救”私有云概念和增强混合云的效果。
2.下一代云：在第二阶段，公共事业、大学、市政府和电信公司（等）将购买云变电站，并向邻近地区开放。这种扩展将开始巩固分布式云代表下一代云计算的基础。当分布式云变电站开始激增时，需要此类服务的用户不必总是购买自己的服务。相反，他们可以使用在附近位置存在的变电站。
图4-分布式云将分两个阶段发展
到2020年，分布式云将开始呈现更正式的形态，因为产品开始以更实质的形式出现，并且组织开始追求与这种计算模式自然契合的边缘部署。作为一个组织，需要花点时间来确定哪些领域可以通过将服务转移到另一个位置（几乎可以肯定是离消费者更近的位置）来改进服务交付和业务价值。
边缘完成云
“边缘”和许多流行语一样，被用于各种各样的上下文和市场中——类似于“云”在过去十年中的用法。Gartner将边缘定义为人和物连接到网络数字世界的物理位置。然而，大多数情况下，“边缘”不用作名词。相反，它用于描述特定的用例或部署方法。从这个意义上说，“边缘”对于技术专家来说，是一个形容词，即与技术或用例结合使用的修饰语。
许多人发现边缘计算几乎等同于物联网。虽然物联网是一个非常一致的用例，但它并不是唯一的用例。在它转移到“核心”基础设施之前，在边缘处理数据，很可能是使用传统设备（如机架服务器）进行处理。当集中化的数据中心或公有云区域不适合给定需求时，将边缘计算视为处理数据和系统的一种方式。
边缘计算是一种拓扑结构，其中信息处理更靠近创建和使用信息的用户和/或设备。云是拓扑结构的核心。
虽然云不必是边缘拓扑的核心，但它通常是。核心为边缘位置提供附加服务、长期存储、集中控制和编排。如果需要边缘部署来提供整个组织所需的每一项服务，那么该部署将有效地成为核心本身。
没有核心的边缘是虚无的边缘。
用例从边缘计算中获益的程度，可以通过分析四项要求来确定。这四项要求包含了边缘部署具有显著积极影响的领域：
■延迟和决定论：光速很快，但不是无限的。将数据传输到核心并接收响应，可能需要太长时间。例如，制造工厂可能需要在毫秒（或更短）的时间内检测出缺陷或机械问题。工厂基础设施和云或数据中心之间的长时间的交换是不可接受的。这个用例需要很强的决定论，即可预测、可重复的响应和响应时间。决定论的好处在于，消除了可能导致更多故障点或抖动的元素。在这种情况下，该元素是两个系统之间的通信，它依赖于网络性能。
■数据和带宽：作为一个技术专家，你一定熟悉图表，它用数据量描述了不可避免的和指数级的上升。这是技术专业人员的生活事实，也是网络带宽如此重要的原因。边缘计算的一个必要条件是它对网络使用的影响。边缘计算可以让组织在不将数据发送到核心的情况下，分析数据并采取适当的行动。这种方法可以大大减轻网络的负担。
■有限的自主权：在个人和专业方面，用户继续受到网络中断和连接不良的影响。在当今世界，用户会从一个几秒钟内无法加载的网站离开，他们希望几乎所有服务都始终保持连接。迟早，你的网络会失败的。在这段时间里，一个能够提供替代服务的边缘部署（即使是以有限的方式）对用户来说也是无价的。
■隐私和安全：一些行业对数据的存储和使用有更严格的要求，但所有组织都有核心安全要求需要满足。无论这种限制是由政府实体实施的，还是由用户期望实施的，确保在必要时存储、处理和删除数据已变得越来越重要。核心基础设施并不总是满足这些要求，经常是因为它位于远离数据源的区域。在位置上进行边缘部署，可以缓解此问题。
2020年，发现适合特定用途用例的组织，将机会主义地利用这一优势。这些用例将是精品，并且有很大程度的定制，因为没有商用现货（COTS）“边缘堆栈”服务于每个人和每个行业的需求。一些常见元素，如设备管理和安全性，在用例之间具有可利用性。不管怎样，2020年并不是在所有方面同时追求优势的一年，但这一年是用优势元素来提升你的环境中的一个良好协调的部分的一年。查看上面的四个要求，并评估应用程序或用例在多大程度上受到影响。
3、重新思考多云、边缘和场内的网络
多年来，组织对云网络的关注主要围绕广域网延迟和带宽、云端虚拟网络以及负载平衡等网络服务。两个新的因素促使组织重新考虑他们的云网络方法：
■软件定义广域网（SD-WAN）的采用，将云网络的关注点扩展到广域网边缘，包括云供应商的虚拟网络在内的组织站点都连接到广域网。
■多云采用迫使组织寻找不仅可以跨云管理虚拟网络，还可以合并数据中心网络的解决方案。数据中心网络供应商，如Arista Networks、Cisco、Juniper Networks和VMware，正在将其基于策略的软件定义网络（SDN）解决方案扩展到云。
为了满足多云提出的不断发展的需求并利用新的网络功能，组织必须：
■对广域网启用云
■利用SD-WAN实现基于应用的网络和云供应商访问
■采用云供应商优先的网络方式
■支持跨云供应商和数据中心实现基于策略管理的SDN解决方案
■使用综合事务和基于代理的监视，来获得云网络的可见性
1）对广域网启用云
组织必须确定互联网和私有传输的正确组合，以满足其云需求。组织可以通过利用AWS Direct Connect、Google cloud Interconnect或Microsoft Azure ExpressRoute等服务的私有互联，将其多协议标签交换（MPLS）网络扩展到云。这样的链接可以提供比因特网连接更多的带宽和更高的可靠性。私有互联也会降低数据传输成本。然而，互联网连接即使不能提供与MPLS连接相同的保障，也能满足一些客户的网络需求。Gartner建议私有互联客户，使用互联网至少增强其MPLS连接以实现冗余。最后，两种连接方法都是首选的，如图5所示。
图5-启用云的广域网
2）利用SD-WAN实现基于应用程序的网络和云供应商访问
SD-WAN通过创建与传输无关的结构，来实现基于应用程序的集中化管理路由。该结构还可以扩展到IaaS云供应商，如图5所示。将结构扩展到云，使组织能够将其云存在视为任何其他的广域网站点，并将这些云置于相同的网络策略之下。
使用SD-WAN，应用程序路由决策将基于网络的当前状态，在某些情况下，基于端到端的应用程序性能。这允许组织利用互联网进行传输。
3）采用云供应商优先的联网方式
组织应在查看第三方结构（如路由器和负载平衡器）之前，评估其云供应商的本地网络结构是否满足其要求。然后，为了填补空白，他们应该实现第三方工具，如深度包检查或高级路由。不同的数据传输成本，会极大地影响云中的网络费用。组织应该将数据进出虚拟私有云（VPC）和虚拟网络（VNet）的成本作为设计参数。如果不加以管理，这种成本可能会迅速上升。
4）支持跨云供应商和数据中心实现基于策略的管理的SDN解决方案
随着企业采用多云和混合方法，跨多个云和本地数据中心创建网络策略变得很困难。SDN覆盖层和数据中心结构解决方案的大多数供应商，现在都将其产品扩展到云中。这些产品使组织能够使用相同的策略和构造集，管理其数据中心和云网络。Gartner预测了两种主要的方法：
■基于API，其中工具利用云API
■基于数据平面，需要将网络设备插入云供应商内部的流量路径内
Gartner建议企业优先考虑通过API管理云的能力，这是任何网络解决方案的要求。
5）使用综合事务和基于代理的监视来获得云网络的可见性
传统的网络监视技术，无论是基于日志、SNMP、流还是数据包，都假定网络运营商：
■拥有网络连接所流经的网络设备
■使用托管服务（如MPLS），并与服务供应商建立了服务水平协议（SLA）
这两个假设都不适用于流经互联网的流量。组织必须部署新技术来弥补可见性差距，因为它们无法监视不属于自己的设备，也无法监视与它们没有建立SLA的链接。Gartner建议使用综合事务（synthetic transactions）来查看流经互联网的流量。生成流量的工具，可以托管在服务器或最终用户设备中。数据收集和处理通常通过SaaS交付，还可以将互联网核心事件与互联网上的客户应用程序性能关联起来。
4、预期并预防供应商锁定，特别是在SaaS层
在云服务中，锁定实际上是不可避免的。锁定从根本上代表云供应商的差异化能力，这通常是供应商价值主张的核心，也是选择该供应商而非竞争对手的原因。在许多情况下，使用云供应商的最有效的方法，是以本地方式接受和充分利用其能力范围。
一般来说，IT系统遵循锁定守恒原理：不管架构如何，整个系统中的锁定量大致相同，但锁定发生的位置根据架构的不同而有所不同。
你不能避免锁定；你只能选择你的锁定点在哪里。因此，确定您选择哪一组风险，以及您将如何降低这些风险。
SaaS有一个附加的锁定维度。除了所有应用程序软件都具有预期的锁定功能之外，SaaS产品通常仅作为云服务提供，而没有在场内运行软件的选项。大多数公司不能轻易地替换应用软件，因为这类应用程序之间的功能差异通常很重要。此外，大多数公司在这些应用程序中实现业务流程，并在多个应用程序之间创建集成。正如您无法轻松地从场内Oracle Siebel CRM软件变更为场内SugarCRM软件一样，您也无法轻松地从那些场内产品切换到SaaS产品，如Oracle CRM On Demand或Salesforce。
基本的IaaS资源，如计算、存储和网络能力，不是商品。软件基础设施服务、PaaS服务和API服务，也都不是（即使它们基于开源软件）。所有这些能力都是根据以下变量区分的：
■功能性
■可用性、性能、安全性、质量和成本特征
■管理和治理
“基础设施即代码”的概念和广泛使用API来集成云服务，导致云依赖直接嵌入到代码中。抽象这些接口并不能显著增强可移植性，因此对锁定的影响很小。
容器的使用可能会从应用程序开发人员的意识中抽象出基础架构问题，但I&O管理员仍然会暴露在这些差异中。此外，I&O管理员还需要处理容器编排和管理。因此，锁定点可能会移动，但它们永远不会消失。使用第三方多云管理工具，只是将锁定转移到这些工具上，而且往往不能充分掩盖提供者的差异，从而提供真正的可移植性。
在实践中，多云组织只需将多个锁定点移到多个供应商，而不必在不同的云供应商之间轻松移植。
为了部分降低锁定风险：
■将锁定视为应用程序可移植性问题，而不是基础设施问题。可移植性应该从单个应用程序的角度来处理。
■为长期的战略应用程序，规划可移植性。封装云供应商接口。例如，将它们放在一个库中，这样依赖关系就清晰了，并且与应用程序代码的其余部分隔离开来。
■考虑使用多云策略，在多个供应商之间分散风险。
■建立云供应商退出策略，预期两年退出的时间框架。
容器和无服务器将日益影响工作负载架构
图2-2020云计算关键规划考虑因素
本部分介绍其中第二项：容器和无服务器将日益影响工作负载架构。
本篇给出了云原生基础设施的演进路线。建议企业考虑支持或构建基于容器和无服务器计算的现代应用程序架构。指出安全应该成为流程和自动化的一个组成部分，反过来，安全应该充分利用这些流程和自动化的优势。
一、容器和无服务器将日益影响工作负载架构
云计算是一个方便的应用程序开发和部署平台，但它并没有覆盖所有出现的组织边界和用例。公司政策、外部合规机构和业务需求，将推动云计算从集中化数据中心转移到分散在边缘位置的基础设施和设备上。
当前的行业趋势是采用基于Docker容器和Kubernetes的容器策略，来打包、构建和部署应用程序。此外，组织越来越习惯于放弃管理基础设施的责任（见图3）。这种趋势的逻辑下一步是无服务器计算——一种按需执行代码的计算方式，只对用户使用的资源收费。在无服务器计算中，服务器对开发人员来说是不可见的，他们只需定义要运行的代码。无服务器平台在后台执行所有必要的配置以运行代码。
图3-云原生属性与抽象层
容器和无服务器功能基于运行时机制，运行时机制的抽象级别高于虚拟机（VM）。在这些抽象级别上，可以以更精细的粒度，将应用程序和服务与资源匹配起来。改进的粒度使编排能够更精确地执行，并且还使得用于应用程序开发的流程和用于迭代部署的流程之间能够更紧密地集成。容器和无服务器功能都是下一代应用程序的关键构建模块，但它们提供了不同的权衡和开发人员体验，使它们在特定的用例中分别与开发人员相关。最近，人们对使用无服务器方法运行容器（无服务器容器）越来越感兴趣，这避免了对大量运维管理的需要。
采用容器和无服务器，增加了现代、分布式基础设施和应用架构的规模和复杂性。为了最佳地管理这个新环境，组织将需要继续投资和开发基础设施自动化。
预计到2020年，大型公有云供应商将进一步推进其自动化工具。云供应商甚至可以构建通用的自动化工具，这些工具可以在其他云或客户自己的数据中心中运行。（微软的Azure自动化工具已经做到了。）今天，没有一个工具可以自动化整个基础设施生命周期。但是，最复杂的公有云自动化工具链可能比任何其他当前可用的工具更接近全生命周期管理。到2020年，I&O专业人员仍应期望构建由不同自动化工具组成的编排工具链。（Gartner客户在整个基础设施自动化生命周期中平均使用8种工具。）但在未来，在公有云中诞生的自动化工具和流程可能会取代单点解决方案阵列，成为自始至终自动化基础设施的单一工具集。
二、规划考虑因素
2020年，I&O专业人员将支持和/或构建基于容器和无服务器计算的现代应用程序架构。他们还将构建由不同自动化工具组成的编排工具链。然而，在未来，公有云中诞生的工具和流程可能会合并为端到端的基础设施自动化的单一工具，取代单点解决方案的集合。因此，I&O专业人员也需要为这种潜在的转变做好准备。
1、使用无服务器基础设施以消除资源调配开销
无服务器基础设施使资源能够用作不透明的、实际上不受限制的共享池，无需预先配置即可连续使用。它还使这些资源能够以消耗的IT服务为单位进行定价。早期人们对无服务器基础设施的大部分兴趣是由函数PaaS（fPaaS，function PaaS）服务驱动的，在该服务中，定制应用程序逻辑的细粒度单元打包为在事件触发时执行的函数。现在，人们对无服务器容器平台的兴趣正在增长，它可以根据不同的需求自动调整后端资源的使用以运行容器。
fPaaS由于其低启动成本和无缝可扩展性而具有吸引力。它消除了供应服务器和配置自动缩放函数所需的运维人员开销。因此，管理人员可以把更多的时间用于生产性任务，而不是把时间花在维护专门支持业务所需的基础设施上。
然而，fPaaS也有一些运维上的限制和挑战。fPaaS函数通常在内存容量和执行时间方面受到限制，需要为纯无状态运维而设计。必须从fPaaS函数获得的任何数据，都必须完全通过函数的回调通知方法或共享持久存储进行通信。由于fPaaS资源完全由云的底层基础设施管理，运维人员的可见性或控制能力有限，这使得测试和调试更加困难。此外，每个云供应商都有自己独特的fPaaS实现，具有用于函数打包和规范的专有API。因此，将fPaaS应用程序迁移到其他云平台将需要一次移植演练。
技术专家应该在这些用例中利用云中的fPaaS：
■基于事件驱动架构（EDA）实现应用程序，EDA是一种开发模型，软件组件在收到一个或多个事件通知后执行动作。
■自动化具有无状态、并发、等幂和可记录特征的运维任务，以及由自助用户行为驱动的运维任务。
■构建需要与云平台及其原生服务进行尽可能高集成的应用程序。如果您承诺使用单个云平台部署应用程序，并且不关心将应用程序移植到其他云服务或本地基础设施，请选择此方法。
无服务器容器平台，如AWS Fargate、Azure container Instances（ACI）和Google Cloud Run（目前处于beta版），使容器能够在没有管理员参与的情况下运行。无服务器容器在容器即服务（CaaS）和fPaaS抽象之间提供了折衷方案。它们为应用程序提供了一个看起来像标准操作系统的环境，但却将大多数容量管理细节卸载到容器编排服务。使用这种方法，管理员不必为容器编排服务配置数据平面（即工作节点）。相反，公有云服务会自动为运行由容器编排器调度的pod提供资源（参见图4）。
图4-无服务器容器编排
无服务器容器平台有一些限制，包括实例类型的狭窄选择和多租户部署的要求。例如，ACI和Fargate支持实例最大为四个CPU，最大内存容量分别为16GB和30GB。这两个服务都不支持专用硬件租赁，因此容器将使用共享资源进行部署。与fPaaS一样，每个云供应商都有自己独特的实现无服务器容器的方法。
在这些情况下，技术专家应该利用云中的无服务器容器：
■他们希望尽可能快地实现容器编排，而无需开发那些运维特定容器编排平台所需的广泛技能。
■它们要求对运行容器的基础设施进行最低限度的可见性或控制。
■容器将在可变工作负载下运行，管理员不想承担配置自动缩放程序的工程挑战。
■容器化工作负载可以在无服务器容器平台的资源限制下，在多租户条件下运行。
■管理员不关心其他云平台或场内基础设施上容器编排的运维一致性。
2、设计可移植性
技术专家必须采取原则性的方法来实现应用程序的可移植性。首先，他们必须有意识地决定是否在应用程序的设计阶段优先考虑可移植性。如果他们决定优先考虑可移植性，那么他们必须遵守促进可移植性的架构原则。这将使应用程序能够在供应商之间移动，而无需进行实质性的重新分层或重构。
当您将可移植性确定为一个重要的优先级时，您应该将云应用程序设计为上下文无关的。作为一种最终状态，上下文无关性很难实现，有时甚至是不可能实现的。上下文无关的三个特征是：
■依赖关系很少：上下文无关的系统几乎可以部署在任何地方，因为它们不依赖于太多其他功能。它们是相对自包含的。
■定义良好的接口：与上下文无关系统的接口方式定义良好，易于理解。
■容易满足的依赖关系：上下文无关系统所具有的少数依赖关系也容易满足。
如表1所示，随着您从SaaS（没有任何特征）向IaaS（三者都有）向下移动，上下文无关性变得更加可能。因此，可移植性在IaaS层最容易实现。
依赖关系很少 | 定义良好的接口 | 容易满足的依赖关系 | |
SaaS | ✗ | ✗ | ✗ |
PaaS | ✗ | ✓ | ✓ |
IaaS | ✓ | ✓ | ✓ |
表1.与云计算分层服务模型相一致的上下文无关原则
要评估可移植性优先级，请考虑每个应用程序的性质，包括它将如何使用以及它可能持续多长时间。在确保系统可靠性和满足快速交付新功能的业务需求之间，权衡取舍。
实现系统可靠性需要关注治理实践，以指导必须长期保持稳定的持续技术和过程创新。相比之下，交付的敏捷性侧重于结果而非过程，侧重于实验而非稳定性，侧重于颠覆性创新而非现状。
如果您的应用程序或工作负载是长寿命的，并且对业务具有战略意义，那么即使您选择使用敏捷开发方法来实现应用程序的某些部分，可移植性也应该是规划的首要和中心。
使用以下条件，评估应用程序工作负载的可移植性优先级：
■可移植性具有更高优先级，当应用程序具有系统性或高度战略性、需要高度的开发工作和/或将持续较长时间时。对于这些应用程序，如果组织在其云应用程序策略中不明确选择可移植性，那么它将承担巨大的风险。
■可移植性具有较低优先级，当应用程序具有更多的机会主义，需要相对最少的开发时间和精力，和/或可能是短暂的时。在这些情况下，“重新开始”可能是一个更便宜和更好的选择。面向低代码（Low-code-oriented）的应用程序属于这一类。
3、制定自动化策略
自动化整个基础设施生命周期是一项复杂的任务，无论是在公有云中还是在场内完成。它需要一个专门的自动化计划，实现这可能需要多年的努力。因此，技术人员必须制定自动化战略。图5描述了一个实施基础设施自动化计划的全面框架。
图5-基础设施自动化计划
该框架可以有效地应用于公有云基础设施。实际上，在公有云中实现计算实例自动化的工作流，与在私有基础设施上实现虚拟机自动化的工作流，没有实质性区别。但是，在每个步骤中，都有一些公有云特有的自动化考虑：
1.准备自动化：公有云基础设施所需的准备工作比典型的场内部署环境少得多。公有云基础设施是由软件定义的：服务通过API提供，并以抽象级别呈现，使它们可以立即被现代自动化工具访问。当自动化场内环境时，I&O团队将花费大量的时间和精力对场内基础设施进行现代化（实际上是使其更像云），作为自动化的一个有利步骤。
2.自动化基础设施交付：主要公有云供应商包含了内置的自动化工具。客户可以使用它们来影响各种部署模式。公有云用户可以使用AWS CodeBuild、Azure DevOps或Google cloud Build等工具，将持续集成和持续交付管道扩展到基础设施。它们还可以使用各种webhook实现基于事件的触发器，或者使用各种供应商提供的发布-订阅技术。在许多情况下，这些工具可以替代第三方部署工具，如HashiCorp Terraform。
3.自动化配置管理：在这里，内置的自动化工具也可以强制系统状态并根据需要部署更改。可以使用AWS CloudFormation、Azure Resource Manager和Automation State Configuration以及Google Cloud Deployment Manager等工具，来代替第三方持续配置自动化（CCA）工具，如Chef、Puppet或Red Hat Ansible。主要的公有云供应商还提供了用于监视、日志管理和补丁的现代实用工具。
4.实现治理现代化：公有云供应商也越来越多地实施现代治理工具和技术。基于策略的管理是可用的，尽管策略通常仅限于一个功能域（如身份和访问管理[IAM]）。主要的公有云还采用了DevSecOps，包括AWS Control Tower和用于Azure的Secure DevOps Kit（工具包）等工具，允许最终用户建立有效的安全和合规控制。
4、拥抱DevSecOps
为整体的DevSecOps方法，调整安全和DevOps实践。安全应该成为流程和自动化的一个组成部分，反过来，它应该充分利用这些流程和自动化的优势。除了支持更灵活的环境之外，这种方法还确保了安全性的一致性和可重复性。它还确保关注构建模块（如工作流定义、脚本、清单和镜像），而不是每个单个的运维和实例化。了解如何加强以及如何支持虚拟化、云、容器、无服务器和数据库环境等多种生态系统中的安全性是关键。例如，图6显示了基于容器的应用程序的自动化部署过程。数字1到11说明了DevSecOps控制可以到达的位置。
图6-自动化部署过程中的威胁向量
并非所有的技术堆栈都具有足够的内置安全性。在这些情况下，组织需要通过第三方组件（如容器安全产品、云工作负载保护平台（CWPP）或运行时应用程序自我保护（RASP）技术）为它们提供安全性。在DevOps环境中，组织还需要改变其脆弱性评估方法。例如，它们不仅需要在工作负载上线后扫描工作负载，还需要在构建期间或实例化之前扫描容器映像。而且，他们需要将安全测试紧密地集成到开发管道中。安全API使这种检测变得更容易，如果这些API还不可用，组织应该要求它们的供应商提供这些API。
组织将重新考虑其对多云和分布式云的运营
图2-2020云计算关键规划考虑因素
之前已经介绍了其中的第一和第二项。本篇介绍其中第三项：组织将重新考虑其对多云和分布式云的运营。第四项略去，不再介绍。
监视和可观察性之间的关键区别：监视的重点是发现“已知的未知量”，而可观察性旨在促进“未知的未知量”的发现。
创建区域云的尝试通常失败。试图将公有云（一种真正的全球化现象）硬塞进民族主义思维，最终是徒劳的。
客户对数据驻留的需求越来越感兴趣。建议有数据驻留需求的客户研究新的加密技术，如多方计算和机密计算。
通过将应用程序控制、系统加固、系统配置优先于以前的基于防病毒的方法，重新调整工作负载安全方法的重点。
一、组织将重新考虑其对多云和分布式云的运营
Gartner的客户正在将更多的公有云计划转移到生产阶段。到2020年，中央IT将负责控制新的异构工作负载，部署在多个IaaS、PaaS、SaaS以及潜在的分布式云解决方案中。云计算的治理具有挑战性，即使只有一个云供应商参与其中。随着组织朝着多云的方向发展，一致地实施治理变得越来越具有挑战性。
开发多云治理和管理流程，对于满足共同的合规性、治理和安全需求至关重要。在2020年，主要的IaaS、PaaS和SaaS供应商将在其产品中提供很少的标准化，而是提供非常不同的功能集、消费工作流、接口和API定义。建立程序化治理，使组织能够使用云服务，同时确保IT维持合规性和卓越的运营性。通过定义和建立策略（无论是否自动化），IT使得业务能够尽可能使用云计算。
此外，云服务的日益采用和多云的日益使用，推动了对一致性的跨平台管理的需求。大规模运维云服务，对负责管理IT系统和服务的技术专家提出了一套新要求。
到2020年，传统的数据中心管理工具将继续提供有限的公有云管理功能。随着新的原生工具和服务的不断发布，云供应商将推进提供更全面管理体验的战略。第三方独立软件供应商（ISV）市场将继续提供快速发展的解决方案，如云管理平台（CMP）和工具。这些工具通过跨平台聚合、一致性或增量功能为云平台增加了管理价值。
二、规划考虑因素
到2020年，大多数组织将接受混合架构作为最终状态目标。多云和分布式云（即边缘）应融入组织的整体IT现代化战略。这将需要评估新的业务方法和投资。要取得成功，IT组织必须：
1、建立多云治理和管理流程
公有云IaaS治理的一种成功方法是在自助服务启用和控制之间微妙平衡的结果。过多的（自助服务）启用将导致混乱。过多的控制将成为生产力和业务创新的障碍，并可能导致更多的影子IT运营。公有云供应商的创新速度很快，快于组织的反应和适应速度。事实证明，试图装模作样或阻碍供应商创新的做法，是一场失败的战斗。因此，组织必须确保其自助服务启用方法，允许直接接触供应商创新，以支持其公有云采用策略的目标。
Gartner的公有云IaaS治理框架，包括以下准备工作和五个步骤：
■第1步-定义策略：定义可编程实施的策略（也称为“护栏”）。您应该编写涵盖以下图3所示的8类云管理的策略，包括“身份、安全和合规性”、“库存清单和分类”和“成本管理和资源优化”。在为公有云治理定义护栏时，必须首先关注指定谁有权访问什么样的云服务，这些个人能做什么，以及在什么条件下。例如，一个策略允许某个用户以管理员身份，从AWS访问Amazon弹性计算云（EC2）服务，但只能在美国东部（北弗吉尼亚州）地区。另一个策略可能允许同一用户作为非管理员工，访问工作日ERP以实现其人力资源功能。
■第2步-实施预防性控制：执行这些策略可防止可能对治理目标最有害的行动（如“保护关键资源和数据”）。实施预防性控制，涉及多个供应商服务，如IAM系统、基于角色的访问控制、资源策略控制和财务审计控制。这些往往是供应商提供的最强大的治理控制。
■第3步-获得总体可见性：一旦对云服务的访问进行了管理，组织必须通过审计工作负载和用户行为、识别违反策略的行为和自动化行动过程，来保持对其云部署的可见性。随着可见度的提高，我们可以通过追溯性的策略实施，来更好地管理和优化云服务的使用。
■第4步-创建审计流程以实施追溯控制：最终用户在管理自己的资源方面获得了更多的自主权。因此，中央IT必须通过审计配置和纠正违反策略的行为，来管理风险和合规性。IT必须在已建立的反馈循环的基础上不断改进治理策略。
■第5步-集成供应商本地和第三方工具：您对多云治理策略的实施，将跨越本地云供应商工具和服务、第三方云管理平台和自定义开发。IaaS和PaaS云供应商已经尝试性地将他们的本地工具扩展到其他有限领域的供应商服务，比如监视。例如，Google Stackdriver Monitoring连接Amazon EC2服务器来收集一些度量和事件。Gartner建议您至少围绕数据存储库（识别资源状态的唯一真实来源）和支持单点登录（SSO）的联合身份，集成管理工具。
2、为多云管理设计工具策略
组织必须通过选择和采用最合适的云管理解决方案组合，来制定云管理工具战略。创建一个一致的云管理工具策略需要一个定义良好的、系统化的方法来巩固需求，并将工具与这些需求相匹配。其目的是在满足所有管理需求的同时，尽量减少所需的工具数量。
组织必须从定义其管理需求开始。这些要求可以是：
■跨平台：所需的功能必须通过具有一致接口的多个云平台交付。
■特定于平台：所需功能特定于一个云平台，并且必须允许访问该特定平台中所有可用的粒度控制。
只有在定义并确定其管理需求的优先级之后，组织才能对云管理工具进行评估、选择和比较。
Gartner建议优先采用云平台的原生工具。这些工具与云平台深度集成，提供了对云平台服务的最高深度和广度的覆盖。此外，它们嵌入在云平台中，不需要单独部署。
在第二阶段，组织还必须选择并采用第三方工具，来解决云平台原生工具中的功能差距，或满足跨平台一致性要求。
图3-云管理转盘
这个框架有助于定义云管理需求和评估CMP和工具的技术能力。该框架提供了215个标准，来对管理私有、混合和公有云IaaS和PaaS的工具进行全面评估。组织可以使用这些标准来定义图3中描述的8个类别（灰色）和4个跨功能属性（蓝色）的需求。
3、拥抱可观察性
长期以来，监视基础设施和应用程序的健康和性能，一直是I&O的明确职责。历史上，有无数的产品和工具（通常由技术或专业团队负责）可用于执行监视功能。各小组相信，他们将得到通知，并准备在出现问题时作出反应。
虽然在过去，这种方法可能已经足够，但是与现代云和云原生解决方案相关联的速度和复杂性，已经削弱了它的可行性。根据阈值或预定义的运行状况检查进行轮询仍然很重要，但这已不足以始终满足服务级别目标（service-level objectives）或确保客户满意。
部分基于控制理论可观测性的软件可观测性，要求有足够丰富的仪器，以允许开发人员和操作员：
■询问软件如何工作的问题
■在与调试比运维更相似的过程中，询问内部状态
监视和可观测性之间的关键区别，可能在于监视的重点是发现“已知的未知量”——即检查错误和事件，这些错误和事件是已知的可能性，因为它们以前发生过。另一方面，可观察性旨在促进“未知的未知量”的发现，即，以前可能从未发生过的情况，以及没有任何检查的情况。
可观测性不是一个在实际情况发生后可以很容易地添加到系统中的属性，例如，当解决方案迁移到生产环境中时，由运维团队添加。需要内置识别和解释未知的未知量所需的仪器。
超规模云供应商提供存储和分析运维遥测的服务。Amazon CloudWatch、AWS CloudTrail和AWS X-Ray、Google Stackdriver和Microsoft Azure Monitor都可以在您的可观察性计划中发挥作用。此外，可以使用云原生遥测源和它们自己的工具并支持可观测软件的其他工具包括：
■大多数应用程序性能监视工具，如Cisco（AppDynamics）、Dynatrace、Instana和New Relic
■监视和时间序列平台，如Datadog、InfloxData和SignalFx（最近由Splunk收购）
■可观测性工具，如Honeycomb和LightStep
■分布式跟踪标准，如OpenCensus和OpenTelemetry
不幸的是，没有菜单可以让人拥抱可观察性。每个人都希望避免的一种情况是，从客户那里收到通知，说某个应用程序或服务不可访问或速度太慢，而监视仪表板则表明一切都很完美。
在大多数情况下，云供应商提供的工具支持可观测性目标（如果被一致使用）。Gartner建议如下：
1.确保平台、框架、工具、服务网格和服务发现机制支持并启用软件可观测性。
2.使用云供应商的监视能力，作为观察托管在那里的工作负载的焦点。对于混合和多云应用程序，大多数基于SaaS的和许多自托管工具都支持Amazon CloudWatch、Microsoft Azure Monitor和Google Stackdriver提供的原生集合。
3.整合定制的工具和度量，使您的软件具有可观察性。OpenTelemetry是为这个用例设计的框架。
4.建立嵌入式仪器的标准，并作为生产准备测试的一部分验证您的可观测性机制。
4、将数据合规性策略扩展到公有云
既然《加州消费者隐私法》（CCPA）于2020年1月1日生效，人们对云计算中的应用程序和数据的隐私工程重新产生了兴趣。在公布时，有十几个国家提出了在范围和影响上类似于或在某些情况下超过了联合国贸易促进委员会的法律草案。在联邦一级，还提出了各种建议，以制定一项一致的、联邦授权的全美国隐私立法。
组织必须创建一个连贯的数据生态系统，避免孤立的环境和零散的数据管理做法。在以数据为中心的安全架构中，技术专家必须设计可以多次使用的隐私保护，以用于现有和未来的隐私规则。
鉴于CCPA和欧盟通用数据保护条例（GDPR）大体相似，Gartner建议采用以下务实的方法，我们可以在客户处观察到GDPR范围内的个人数据。这些方法是一个起点，以将隐私设计到基于云的项目或部署中：
■了解贵公司正在使用的云服务。在部门级别，IaaS、PaaS和业务提供的SaaS服务可能更容易解释。然而，较小的团队或个人也可能使用额外的SaaS服务，以使他们的生活更轻松。了解数据真正去向的一种方法，是在边界实现云访问安全代理（CASB）。
■策划组织支持的云服务的正式列表。CCPA范围内的所有服务和供应商必须提供实施相关控制的方法，如数据发现、数据生命周期管理或数据主体访问请求（DSAR，data subject access requests）。并非所有要求都适用于每个基于云的数据仓库。
■如果您停止使用云服务，请确保您可以删除个人数据。对于IaaS，这可以通过使用静态数据加密来完成，该加密允许您携带自己的密钥（数字粉碎）。如果您使用对象（或blob）存储，或者更高级别的PaaS和SaaS服务，则流程会更复杂。尽管后一种服务可能会透明地加密您的数据，但它们可能无法让您控制加密密钥。
■认识到高级控制（如在云中处理数据之前屏蔽数据）适合匿名化个人数据，并使您的云部署超出CCPA的范围。
在国际上，客户对数据驻留的需求越来越感兴趣，但云服务供应商仍在努力解决如何最好地满足这些要求。创建区域云的尝试通常失败。例如，微软已经宣布停止其德国数据托管模式，并将把德国Azure和Office 365区域重新纳入全球微软的阵营。
试图将公有云（一种真正的全球化现象）硬塞进民族主义思维，最终是徒劳的。当一个组织开始在一个超规模云中存储数据并执行计算时，该组织开始失去对其数据位置的控制。尽管供应商提供名义上的驻留形式，但客户应该预料到意想不到的副作用。
Gartner建议有数据驻留需求的客户研究新的加密技术，如多方计算和机密计算，它们声称可以有效地使云服务供应商（CSP）对客户数据视而不见。
5、将数据可用性策略扩展到公有云
从导致航班取消的停电到导致存储无法访问的人为错误，无论系统位于何处或由谁管理，系统都可能出现故障。无论服务位于何处，关键任务服务的可用性和公司数据的保护都至关重要。保护这些数据（通常是组织拥有的最重要资产）是一项信托责任，需要一个全面的数据可用性策略。
到2020年，使用公有云IaaS作为其数据中心备份目的地的企业数量，将从2017年初的10%增加至翻一番。
IT服务不再完全在场内提供。利用公有云服务的混合配置现在是默认配置。尽管IaaS、PaaS和SaaS供应商提供数据弹性，但大多数都不提供本地备份或自动故障转移。这些分布式架构的部署模型，迫使IT经理和业务连续性规划人员重新考虑传统的备份和数据恢复（DR）策略。现有的数据中心解决方案，提供了稳健、成熟的数据保护，但必须重新评估，以确保对所有基于云的组件的支持。此外，对网络攻击和勒索软件威胁的认识提升，正促使各组织审查其灾难恢复能力和灾难恢复准备计划。
云供应商继续投资于他们的架构，使其具有高度的弹性和可用性。但是，弹性和可用性不足以防止意外删除、意外中断、恶意意图或糟糕的软件导致的数据丢失或损坏。目前，云供应商的本地恢复工具有限且不成熟，在数据保护方面存在明显差距。虽然云供应商将尽一切努力保存数据，但他们通常不提供具有集中的基于策略的计划和保留的企业级备份，也不提供细粒度的数据恢复选项。
基于SaaS的服务供应商也是如此。组织对数据恢复（或赔偿）没有追索权。无论数据丢失是由服务中断、硬件故障、数据损坏、恶意操作还是意外删除造成的，他们都要全权负责数据的备份/恢复。对于违反SLA的情况，可以提供部分服务信用。但是，每月费用的减少并不包括潜在的大量数据替换工作和成本，也不包括由于法律合规性处罚而造成的损失。
在2020年，Gartner建议企业重新评估其数据可用性和灾难恢复策略，以支持场内和基于云的工作负载。建议包括：
■利用基于云的IaaS服务：与公有云存储的集成，已成为企业备份解决方案的标准。磁盘到磁盘到云（D2D2C）备份方法允许您维护现场备份镜像，以便快速恢复大型数据集，同时将访问频率较低的长期保留数据放置在云存储层中。目前将远程办公室或端点用户数据备份到本地磁带的解决方案，可以被直接将数据备份到云的成本更低、更易于管理的解决方案所取代。
基于云的灾难恢复和灾难恢复即服务（DRAA）进一步扩展了这一概念。这些方法通过利用直接复制到云存储的基于云的备份数据或主数据，使工作负载能够在云中运行。云恢复作为另一级场内数据中心的替代方案，可以消除设备成本并最大限度地减少备用灾难恢复IT基础架构，从而降低资本开支和管理开销。
■评估当前场内数据可用性工具和流程的云可行性：例如，评估备份、数据复制和灾难恢复的编排能力，以确定它们是否可以扩展以支持基于云的工作负载和数据。随着越来越多的任务关键型工作负载迁移到云中或诞生在云中，需要备份/恢复和灾难恢复等标准运维过程来支持它们。传统的场内备份解决方案包括强大的功能和成熟的管理功能，但它们不是为云部署或按需许可模式而设计的。
尽管这些解决方案中有许多基于代理的选项支持公有云VM，但您通常必须先获得自己的许可证并购买基于容量的软件。您应该利用较新的备份即服务（BaaS）供应商的产品，这些产品可以与订阅、基于使用的消费模型一起部署，并可以与云实践保持一致。IaaS和SaaS可能需要单独的解决方案，因此请寻找支持基于SaaS的领先的应用程序的供应商，包括Google G Suite、Microsoft Office 365和Salesforce产品。
鉴于数据可用性的敏感性和重要性，重新考虑和重新架构对所有数据中心和基于云的数据的保护，必须是当务之急。
调整业务政策以整合基于云的数据保护策略
在向更注重云的备份和灾难恢复计划转变的过程中，企业应该将业务需求与市场上可用的技术相结合。在为组织实施基于SaaS的解决方案时，I&O专业人员应首先调查SaaS供应商提供的本地数据保护能力。然后，他们应该与实施SaaS解决方案的业务经理和团队合作，了解他们对数据保护和保留的需求。
分析公司当前的备份和灾难恢复软件解决方案，以确定它们是否适合SaaS应用程序。评估所提供的能力是否能够提供所需的保护级别。对于每个应用程序，确定数据所在的位置（例如，场内或云）以及如何最好地备份该数据。最后，调整策略以整合SaaS和基于云的应用程序，以确保满足公司最佳实践，并考虑适当的治理和安全。
上述步骤总结如下：
1.审查当前的组织备份策略，以了解基于SaaS的应用程序适合哪里。
2.确定您需要在哪里实施第三方解决方案，以解决公有云供应商的本地数据保护工具中的差距。
3.制定一项战略，重点满足企业在云端的备份和数据保护方面的需求。具体来说，解决与恢复点目标（RPO）和恢复时间目标（RTO）相关的公司策略。
6、对公有云安全控制实践的再思考
云中的工作负载和数据必须与场内的工作负载和数据处于相同的安全级别。虽然本地CSP控制确实很有用，但它们通常不太直观，而且过于关注自己的环境。相比之下，客户需要跨越多个云的直观控制。
为了抵御云部署的各种威胁，CWPP提供了跨VM、容器、PaaS工作负载和无服务器工作负载的安全和保护功能。它们提供入侵防御、完整性控制和应用程序控制等核心服务，以及加固、配置和差异化纵深防御的安全能力。供应商的能力通常集中在7个分组上。图4通过比较这些分组能力如何最好地处理一组威胁场景，来分析这些分组功能。
图4.CWPP变体的“DNA标记”类比图
图4显示了CWPP供应商工具中的关键功能。已识别出7种CWPP变体，这些变体因工具传统和技术重点而异：
■广谱：这一类别包括更大的供应商，他们将其他工具融合在一起，以产生跨多个操作系统（OS）的多方面服务能力。
■聚焦于容器：一般来说，这一类别涵盖了一系列广泛的能力，重点放在容器部署上。
■网络和微分段：这些工具支持使用基于主机的防火墙对计算平台进行逻辑隔离的综合方法。它们在网络层和应用程序层提供可见性控制。它们还提供网络安全、访问控制和威胁情报服务。
■内存和进程完整性保护：这些工具保护计算服务，确保内存和进程的完整性。这些工具还将其他服务放在计算保护之上，例如严格的应用程序控制、加固和配置。
■聚焦于无服务器：这些工具旨在保护无服务器、基于功能的云计算服务。他们主要关注应用程序控制、访问控制和用户行为分析。
■聚焦于EDR：这一类别包括将端点检测和响应（EDR）功能扩展到云中的供应商。这些工具增加了配置和加固功能，以及工作负载行为监视和威胁检测。
■脆弱性、加固和配置合规性：这类工具来自合规平台。它们重点关注持续的合规性、资产清单和漏洞报告。
选择正确的CWPP能力来增强云安全性，对技术专家来说是一个挑战。我们的建议可以促进这一进程：
■选择一个CWPP供应商工具，该工具涵盖公有云供应商的本地工作负载安全服务未解决的已识别能力差距。CWPP还可以为跨不同IaaS部署的工作负载提供一致性。
■使用CWPP提高可见性，以便您能够对异常和未经授权的工作负载行为进行检测和响应。此外，使用CWPP来加强控制，以便可以限制所有运行时工作负载的威胁机会。
■利用CWPP工具，提供为应用程序和系统行为形成基线的方法。然后，报告偏差以尽量减少误报。
■通过将应用程序控制、系统加固和系统配置优先于以前的基于防病毒的方法，重新调整工作负载安全方法的重点。
声明：本文来自蓝海科学，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
