OAM 深入解读：OAM 为云原生应用带来哪些价值？

背景

之前我们已经发布过一系列介绍文章，为方便大家查阅，链接和介绍如下：

• 《4 个概念，1 个动作，让应用管理变得更简单》：具体而详实的介绍了 OAM 方方面面的细节；

• 《给 K8s API “做减法”：阿里巴巴云原生应用管理的挑战和实践》：介绍了我们在探索出 OAM 之前的一些实践背景以及为什么会自然而然地设计出 OAM 这样的应用模型；

• 《OAM 加持下的 Kubernetes PaaS 应用管理实践》：围绕目前常见的基于 Kubernetes 构建 PaaS 的各类解决方案，介绍了 OAM 如何将这些方案有机结合并最终统一，然后进一步的通过标准化模块化的组织，发挥生态的力量，使得彼此协作互惠互利成为可能；

• 《开放应用模型操作指南（一）：云服务“一键接入” OAM 体系》：以云资源为例，介绍了如何介入 OAM 体系的方法和实践。

在上面的几篇文章中，我们介绍了为什么云原生应用需要标准定义，以及 OAM 模型到底是什么样子的。今天则为大家介绍 OAM 本身有哪些价值，即回答为什么是使用 OAM 来作为应用标准模型。

AWS 构建 ECS CLI v2 的开发原则

去年底（2019 年 12 月），AWS 发布了 ECS CLI v2，这是自 2015 年发布 v1 以后，四年来首次发布的大版本更新，这次发布的 v2 版本命令行工具将更关注端到端的应用体验，即管理从源代码开发到应用部署的全方位应用交付流程。

他们基于多年来收到的用户反馈总结了四条 CLI 的开发原则：

• 默认创建现代化的应用。创建的现代化应用默认满足这几个特征：无服务化 (serverless)，基础设施即代码 (infrastructure as code)，可观测 (observable)，安全 (secure)；

• 用户应该考虑的是架构，而不是基础设施。开发者构建微服务的时候，不应该指定 VPC、负载均衡配置亦或是复杂的 Pipeline 流程配置。开发者可以对云服务一无所知，但是他们应该制定应用到底属于哪种类型，即应用应该适配哪种架构，基础设施应该根据应用指定的架构自动匹配资源；

• 运维也应该是工作流的一部分。应用的构建、开发、部署只是应用生命周期中由应用开发者负责的一部分。应用的全生命周期中还应该包含运维的部分，即问题排查和解决；

• 应用交付是持续的。应用的升级变更也应该方便地集成到 CI/CD 系统中。

这几条原则与其说是 ECS CLI 的开发原则，不如说是用户的诉求：

• 用户希望他们的应用是现代化的（或者说云原生化的）；

• 用户希望他们指定架构，而不是具体的基础设施资源；

• 用户希望运维能力也被统一管理进应用的生命周期；

• 用户希望应用的变更交付可以持续、透明、方便的对接并被 CI/CD 系统管理。

OAM 模型的价值

针对上述用户的诉求，我们一个个来看 OAM 是如何满足的，同时也能看出 OAM 在其中发挥的价值。

1. 云原生化

• OAM 应用定义是声明式的，即面向终态的，它的格式与 K8s 的 API 一致，可以与 K8s 的 CRD 无缝对接，直接作为 Custom Resource 的 Object 部署到 K8s；

• OAM 应用定义是自包含的，通过 OAM 定义的描述可以找到包含一个应用生命周期中方方面面所有的信息。

如下图所示，你可以看到运行 OAM 的一个应用配置，使用 K8s 的 API spec，完整包含了一个应用方方面面的资源。

2. 平台无关、运行时无关

OAM 应用定义并不限定你底层的平台和实际运行时，你完全可以运行在 K8s 以外的平台，不管是 ECS、Docker、又或是 FaaS (Serverless)，自然也不存在厂商锁定的问题。如果你的应用满足 Serverless 的条件，那么针对该应用的 OAM 描述，天然就可以运行在支持 OAM 规范的 Serverless 运行时。

在支持 OAM 的不同环境中，你便可以使用统一的应用描述，打造无差别的应用交付。就如下图所示，对应用户，他们只要描述统一的应用配置，便可以在不同的环境达到一致的应用体验。

3. 基础设施即代码

云原生的普及很大程度上推动了基础设施即代码的实现，K8s 作为一个基础设施平台，通过声明式 API，让用户习惯了通过 Yaml 文件描述需要的资源，这其实就是基础设施即代码的实现。而 OAM 更进一步，它将原生 K8s 中没有包含的基础设施资源也统一定义起来，通过配置 OAM 规范的 yaml（代码）来使用基础设施。

如今阿里云上的资源编排产品 ROS 的 OAM 实现就是这样一个典范，你完全可以通过 OAM 的配置拉起一个云上的基础设施资源。

让我们来实际看一个例子，为拉起一个 NAS 持久化存储，其中包含两个 ROS 的资源，分别为 NAS FileSystem 和 NAS MountTarget。

apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata:  name: nasFileSystem  annotations:    version: v1.0.0    description: >      component schematic that describes the nas filesystem.spec:  workloadType: ros.aliyun.com/v1alpha1.NAS_FileSystem  workloadSettings:    ProtocolType: NFS    StorageType: Performance    Description: xxx  expose:    - name: fileSystemOut---apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata:  name: nasMountTarget  annotations:    version: v1.0.0    description: >      component schematic that describes the nas filesystem.spec:  workloadType: ros.aliyun.com/v1alpha1.NAS_MountTarget  workloadSettings:    NetworkType: VPC    AccessGroupName: xxx    FileSystemId: ${fileSystemOut.FileSystemId}  consume:    - name: fileSystemOut  expose:    - name: moutTargetOut ---apiVersion: core.oam.dev/v1alpha1kind: ApplicationConfigurationmetadata:  name: nas-demospec:  components:    - componentName: nasMountTarget      traits:        - name: DeletionPolicy          properties: "Retain"    - componentName: nasFileSystem      traits:        - name: DeletionPolicy          properties: "Retain"

在定义中，你可以看到 NAS MountTarget 使用了 NAS FileSystem 输出的 FileSystemId，最终这个 yaml 会由 ROS 的 OAM Controller 翻译为 ROS 的资源栈模板文件，最终拉起云上的资源。

ROS 的 OAM 实现也将在不久之后开源，敬请期待！

4. 关心架构而不是基础设施

用户的诉求其实是应用的架构，而不是具体使用哪种基础设施资源。

而 OAM 通过 “WorkloadType” 来解决这个诉求，通过描述一个应用的 WorkloadType 来定义应用的架构，这个 WorkloadType 可以是简单的无状态应用 “Server”，表示应用可复制、可访问、并作为守护进程长久运行；也可以是一个数据库类型的应用 “RDS”，对应启动一个云上的 RDS 实例。

用户的组件 “Component” 通过指定 “WorkloadType” 选择具体的架构模板，多个 Component 构成了完整的架构。

使用 OAM 应用定义让用户真正关心的是架构，而不是具体的基础设施。

如下图所示，OAM 的一个应用描述，用户指定它的应用需要一个外网访问能力，而不是指定一个 SLB，用户指定它的组件是数据库的。

5. 运维能力管理

用户希望运维能力也是应用生命周期的一部分，而 OAM 正是如此，通过绑定 Trait，来定义一个 Component 所使用到的运维能力，从而把运维能力也加入到应用描述中，方便底层基础设施统一管理。

如下图所示，一个应用包含两部分组件，一个 web 服务和一个数据库， 数据库组件应该具有数据备份的能力，而 web 服务则可以被访问、可以弹性扩缩容。这些能力由 OAM 的解释器（即 OAM 的实现层）统一管理，从此运维能力绑定出现冲突也不再是烦恼。

6. 透明化的集成

就像 Docker 镜像解决了长久以来开发、测试、生产环境不一致一样，统一而标准化的 OAM 应用描述也让不同系统之间的集成变得透明而标准化。

7. 不同的角色关注点分离

OAM 也将原先 K8s All-in-one 的复杂 API 做了一定层次的解耦，分为应用研发（管理 Component）、应用运维（将 Component 组合并绑定 Trait 变成 AppConfig）、以及基础设施提供方（提供 OAM 的解释能力映射到实际的基础设施）三大角色，不同角色分工协作，从而整体简化单个角色关注的内容。使得不同角色可以更聚焦更专业的做好本角色的工作。

8. 弹性可扩展

OAM 应用定义是弹性、可扩展的，你可以通过扩展 Workload 来定义不同类型的工作负载，你也可以通过自定义的 Trait 来描述你的运维能力，而且都可以与现有的 K8s 体系里面 CRD+Operator 的扩展方式完美结合。

9. 模块化协作

OAM 通过关注点分离的思想，将应用分为研发、运维和基础设施三个层次，同时又为研发的 Workload 和运维的 Trait 提供了模块化协作的能力，大大提高了复用能力。

当模块化的 Workload 和 Trait 越来越多，就会形成这些组件的市场，用户可以在 CRD Registry 这样的注册中心，快速找到适合自己的应用的架构（Workload），以及自己需要使用的运维能力（Trait）。构建应用将越来越简单。

未来

相信应用的构建会越来越简单，基础设施的选择会根据用户的架构需求自动匹配，用户可以真正享受到云平台化的红利，快速复用已有的模块化能力，而 OAM 也将成为应用云原生化的必然选择。

目前，阿里巴巴团队正在上游贡献和维护这套技术，如果大家有什么问题或者反馈，也非常欢迎与我们在上游或者钉钉联系。

本文转载自公众号阿里巴巴云原生（ID：Alicloudnative）。

原文链接：

https://mp.weixin.qq.com/s/7nkUqDNXzehIUnbGBPG8dQ