Gartner 2020年规划指南 | 云计算（中）
全文约5300字 6图 阅读约15分钟
本文是Gartner《2020年规划指南》的十个分报告之一，介绍了企业上云的规划趋势。云已经成为企业转型和获得竞争优势的基础，云将继续作为数字业务所需的创新平台。企业应确保云成为组织中的主流计算平台，并将其混合云和多云战略扩展到边缘。
本篇给出了云原生基础设施的演进路线。建议企业考虑支持或构建基于容器和无服务器计算的现代应用程序架构。指出安全应该成为流程和自动化的一个组成部分，反过来，安全应该充分利用这些流程和自动化的优势。
同系列相关阅读
图1-《Gartner规划指南》十大领域（分报告）
图2-2020云计算关键规划考虑因素
我们将分别对图中四大趋势及其规划考虑作进一步描述。考虑到该报告太长，计划分为几篇分别介绍。本次介绍其中第二项：容器和无服务器将日益影响工作负载架构。
云计算是一个方便的应用程序开发和部署平台，但它并没有覆盖所有出现的组织边界和用例。公司政策、外部合规机构和业务需求，将推动云计算从集中化数据中心转移到分散在边缘位置的基础设施和设备上。
当前的行业趋势是采用基于Docker容器和Kubernetes的容器策略，来打包、构建和部署应用程序。此外，组织越来越习惯于放弃管理基础设施的责任（见图3）。这种趋势的逻辑下一步是无服务器计算——一种按需执行代码的计算方式，只对用户使用的资源收费。在无服务器计算中，服务器对开发人员来说是不可见的，他们只需定义要运行的代码。无服务器平台在后台执行所有必要的配置以运行代码。
图3-云原生属性与抽象层
容器和无服务器功能基于运行时机制，运行时机制的抽象级别高于虚拟机（VM）。在这些抽象级别上，可以以更精细的粒度，将应用程序和服务与资源匹配起来。改进的粒度使编排能够更精确地执行，并且还使得用于应用程序开发的流程和用于迭代部署的流程之间能够更紧密地集成。容器和无服务器功能都是下一代应用程序的关键构建模块，但它们提供了不同的权衡和开发人员体验，使它们在特定的用例中分别与开发人员相关。最近，人们对使用无服务器方法运行容器（无服务器容器）越来越感兴趣，这避免了对大量运维管理的需要。
采用容器和无服务器，增加了现代、分布式基础设施和应用架构的规模和复杂性。为了最佳地管理这个新环境，组织将需要继续投资和开发基础设施自动化。
预计到2020年，大型公有云供应商将进一步推进其自动化工具。云供应商甚至可以构建通用的自动化工具，这些工具可以在其他云或客户自己的数据中心中运行。（微软的Azure自动化工具已经做到了。）今天，没有一个工具可以自动化整个基础设施生命周期。但是，最复杂的公有云自动化工具链可能比任何其他当前可用的工具更接近全生命周期管理。到2020年，I&O专业人员仍应期望构建由不同自动化工具组成的编排工具链。（Gartner客户在整个基础设施自动化生命周期中平均使用8种工具。）但在未来，在公有云中诞生的自动化工具和流程可能会取代单点解决方案阵列，成为自始至终自动化基础设施的单一工具集。
2020年，I&O专业人员将支持和/或构建基于容器和无服务器计算的现代应用程序架构。他们还将构建由不同自动化工具组成的编排工具链。然而，在未来，公有云中诞生的工具和流程可能会合并为端到端的基础设施自动化的单一工具，取代单点解决方案的集合。因此，I&O专业人员也需要为这种潜在的转变做好准备。
无服务器基础设施使资源能够用作不透明的、实际上不受限制的共享池，无需预先配置即可连续使用。它还使这些资源能够以消耗的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一样，每个云供应商都有自己独特的实现无服务器容器的方法。
在这些情况下，技术专家应该利用云中的无服务器容器：
■他们希望尽可能快地实现容器编排，而无需开发那些运维特定容器编排平台所需的广泛技能。
■它们要求对运行容器的基础设施进行最低限度的可见性或控制。
■容器将在可变工作负载下运行，管理员不想承担配置自动缩放程序的工程挑战。
■容器化工作负载可以在无服务器容器平台的资源限制下，在多租户条件下运行。
■管理员不关心其他云平台或场内基础设施上容器编排的运维一致性。
技术专家必须采取原则性的方法来实现应用程序的可移植性。首先，他们必须有意识地决定是否在应用程序的设计阶段优先考虑可移植性。如果他们决定优先考虑可移植性，那么他们必须遵守促进可移植性的架构原则。这将使应用程序能够在供应商之间移动，而无需进行实质性的重新分层或重构。
当您将可移植性确定为一个重要的优先级时，您应该将云应用程序设计为上下文无关的。作为一种最终状态，上下文无关性很难实现，有时甚至是不可能实现的。上下文无关的三个特征是：
■依赖关系很少：上下文无关的系统几乎可以部署在任何地方，因为它们不依赖于太多其他功能。它们是相对自包含的。
■定义良好的接口：与上下文无关系统的接口方式定义良好，易于理解。
■容易满足的依赖关系：上下文无关系统所具有的少数依赖关系也容易满足。
如表1所示，随着您从SaaS（没有任何特征）向IaaS（三者都有）向下移动，上下文无关性变得更加可能。因此，可移植性在IaaS层最容易实现。
依赖关系很少 | 定义良好的接口 | 容易满足的依赖关系 | |
SaaS | ✗ | ✗ | ✗ |
PaaS | ✗ | ✓ | ✓ |
IaaS | ✓ | ✓ | ✓ |
表1.与云计算分层服务模型相一致的上下文无关原则
要评估可移植性优先级，请考虑每个应用程序的性质，包括它将如何使用以及它可能持续多长时间。在确保系统可靠性和满足快速交付新功能的业务需求之间，权衡取舍。
实现系统可靠性需要关注治理实践，以指导必须长期保持稳定的持续技术和过程创新。相比之下，交付的敏捷性侧重于结果而非过程，侧重于实验而非稳定性，侧重于颠覆性创新而非现状。
如果您的应用程序或工作负载是长寿命的，并且对业务具有战略意义，那么即使您选择使用敏捷开发方法来实现应用程序的某些部分，可移植性也应该是规划的首要和中心。
使用以下条件，评估应用程序工作负载的可移植性优先级：
■可移植性具有更高优先级，当应用程序具有系统性或高度战略性、需要高度的开发工作和/或将持续较长时间时。对于这些应用程序，如果组织在其云应用程序策略中不明确选择可移植性，那么它将承担巨大的风险。
■可移植性具有较低优先级，当应用程序具有更多的机会主义，需要相对最少的开发时间和精力，和/或可能是短暂的时。在这些情况下，“重新开始”可能是一个更便宜和更好的选择。面向低代码（Low-code-oriented）的应用程序属于这一类。
自动化整个基础设施生命周期是一项复杂的任务，无论是在公有云中还是在场内完成。它需要一个专门的自动化计划，实现这可能需要多年的努力。因此，技术人员必须制定自动化战略。图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（工具包）等工具，允许最终用户建立有效的安全和合规控制。
为整体的DevSecOps方法，调整安全和DevOps实践。安全应该成为流程和自动化的一个组成部分，反过来，它应该充分利用这些流程和自动化的优势。除了支持更灵活的环境之外，这种方法还确保了安全性的一致性和可重复性。它还确保关注构建模块（如工作流定义、脚本、清单和镜像），而不是每个单个的运维和实例化。了解如何加强以及如何支持虚拟化、云、容器、无服务器和数据库环境等多种生态系统中的安全性是关键。例如，图6显示了基于容器的应用程序的自动化部署过程。数字1到11说明了DevSecOps控制可以到达的位置。
图6-自动化部署过程中的威胁向量
并非所有的技术堆栈都具有足够的内置安全性。在这些情况下，组织需要通过第三方组件（如容器安全产品、云工作负载保护平台（CWPP）或运行时应用程序自我保护（RASP）技术）为它们提供安全性。在DevOps环境中，组织还需要改变其脆弱性评估方法。例如，它们不仅需要在工作负载上线后扫描工作负载，还需要在构建期间或实例化之前扫描容器映像。而且，他们需要将安全测试紧密地集成到开发管道中。安全API使这种检测变得更容易，如果这些API还不可用，组织应该要求它们的供应商提供这些API。
（中篇完）