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

发布于:2020 年 2 月 9 日 10:30

前阿里 P9 技术专家 李运华,正在传授十几年架构实战心法,超过 46000 人跟随学习,点击查看 >>
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,完整包含了一个应用方方面面的资源。

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

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

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

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

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

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

3. 基础设施即代码

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

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

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

复制代码
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: nasFileSystem
annotations:
version: v1.0.0
description: >
component schematic that describes the nas filesystem.
{1}spec:
workloadType: ros.aliyun.com/v1alpha1.NAS_FileSystem
workloadSettings:
ProtocolType: NFS
StorageType: Performance
Description: xxx
expose:
- name: fileSystemOut
---
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: nasMountTarget
annotations:
version: v1.0.0
description: >
component schematic that describes the nas filesystem.
{1}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/v1alpha1
kind: ApplicationConfiguration
metadata:
name: nas-demo
spec:
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,用户指定它的组件是数据库的。

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

5. 运维能力管理

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

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

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

6. 透明化的集成

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

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

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

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

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

8. 弹性可扩展

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

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

9. 模块化协作

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

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

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

未来

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

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

本文转载自公众号阿里巴巴云原生(ID:Alicloudnative)。

原文链接

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

阅读数:1863 发布于:2020 年 2 月 9 日 10:30

更多 云原生、架构、安全 相关课程,可下载【 极客时间 】App 免费领取 >

评论 (1 条评论)

发布
用户头像
云原生已渡过了野蛮生长期,正朝着统一应用标准方向迈进。
Kubernetes 的原语无法完整描述云原生应用体系,且在对资源的配置上开发与运维功能耦合严重。
Operator 在扩展了 Kubernetes 生态的同时导致云原生应用碎片化,亟需一个统一的应用定义标准。
OAM 的本质是将云原生应用的定义中的研发、运维关注点分离,资源对象进行进一步抽象,化繁为简,高罗万象。
https://jimmysong.io/guide-to-cloud-native-app/docs/post-kubernetes-era/
“Kubernetes 次世代”是指在 Kubernetes 成为基础设施层标准之后,云原生生态的关注点正在向应用层过度,近两年来火热的 Service Mesh 正式该过程中的一次有力探索,而基于 Kubernetes 之上的云原生应用架构的时代即将到来。
展开
2020 年 05 月 25 日 11:14
回复
没有更多评论了