开发者社区> wonderflow> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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

简介: # 背景 OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范,之前我们已经发布过一系列介绍文章,为方便大家查阅,链接和介绍如下: * [《Open Application Model (OAM) 实践指南》](https://www.atatech.org/articles/155780):具体而详实的介绍了OAM方方面面的细节。 * [《给 K8s API
+关注继续查看

背景

OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范,之前我们已经发布过一系列介绍文章,为方便大家查阅,链接和介绍如下:

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

AWS 构建 ECS CLI v2 的开发原则

本月初(2019年12月),AWS 发布了 ECS CLI v2,这是自2015年发布 v1 以后,四年来首次发布的大版本更新,这次发布的 v2 版本命令行工具将更关注端到端的应用体验,即管理从源代码开发到应用部署的全方位应用交付流程。他们基于多年来收到的用户反馈总结了四条CLI的开发原则:

  1. 默认创建现代化的应用。创建的现代化应用默认满足这几个特征:无服务化(serverless),基础设施即代码(infrastructure as code),可观测(observable),安全(secure)。
  2. 用户应该考虑的是架构,而不是基础设施。开发者构建微服务的时候,不应该指定VPC、负载均衡配置亦或是复杂的Pipeline流程配置。开发者可以对云服务一无所知,但是他们应该制定应用到底属于哪种类型,即应用应该适配哪种架构,基础设施应该根据应用指定的架构自动匹配资源。
  3. 运维也应该是工作流的一部分。应用的构建、开发、部署只是应用生命周期中由应用开发者负责的一部分。应用的全生命周期中还应该包含运维的部分,即问题排查和解决。
  4. 应用交付是持续的。应用的升级变更也应该方便的集成到 CI/CD 系统中。

这几条原则与其说是 ECS CLI 的开发原则,不如说是用户的诉求,用户希望他们的应用是现代化的(或者说云原生化的);用户希望他们指定架构,而不是具体的基础设施资源;用户希望运维能力也被统一管理进应用的生命周期;用户希望应用的变更交付可以持续、透明、方便的对接并被 CI/CD 系统管理。

OAM 模型的价值

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

云原生化

  • OAM 应用定义是声明式的,即面向终态的,它的格式与 K8s 的 API 一致,可以与 K8s 的 CRD 无缝对接,直接作为 Custom Resource 的 Object 部署到 K8s。
  • OAM 应用定义是自包含的,通过 OAM 定义的描述可以找到包含一个应用生命周期中方方面面所有的信息。

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

image.png

平台无关、运行时无关

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

image.png

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

image.png

基础设施即代码

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

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

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

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  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/v1alpha1
kind: ComponentSchematic
metadata:
  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/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 的资源栈模板文件,最终拉起云上的资源。

关心架构而不是基础设施

用户的诉求其实是应用的架构,而不是具体使用哪种基础设施资源。而 OAM 通过 “WorkloadType” 来解决这个诉求,通过描述一个应用的 WorkloadType 来定义应用的架构,这个WorkloadType可以是简单的无状态应用“Server”,表示应用可复制、可访问、并作为守护进程长久运行;也可以是一个数据库类型的应用“RDS”,对应启动一个云上的RDS实例。

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

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

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

image.png

运维能力管理

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

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

image.png

透明化的集成

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

image.png

不同的角色关注点分离

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

image.png

弹性可扩展

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

image.png

模块化协作

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

image.png

未来

相信OAM会成为应用云原生化的必然选择。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
云ECS的使用体验
一次使用体验的记录
22 0
深入探索云原生流水线的架构设计
目前,市面上的流水线/工作流产品层出不穷,有没有一款工作流引擎,能够同时满足各种繁复的需求?一起来看!
68 0
学生云ECS使用体验
菜鸡初步使用阿里云ECS体验
45 0
为什么云原生应用程序是未来
现在,每个人都在谈论如今在云原生态环境中构建的应用程序。什么是云原生的,为什么它如此重要?     在深入挖掘之前,可以先看看一个有趣的陈述。据调研机构IDC称,到2022年,90%的新应用都将采用微服务架构,提高设计、调试、更新和利用第三方代码的能力;所有生产应用程序的35%将是云原生的。     显然,未来属于云原生应用程序。现在看一下云原生的定义。     云原生(或基于云计算)应用程序是在云中创建的应用程序,它是作为打包在容器中的微服务构建的。  
54 0
端应用研发进入云原生时代
随着技术的发展和各种用户端场景的涌现,业务前台形式变得更加多样,“面向多样化的端场景提供无缝的、一致的数字用户旅程”已经成为了新时代企业应用架构的关键目标,同时它也是当下大前端技术发展背后的核心业务牵引。基于阿里云在过去几年服务海量用户的经验沉淀,本文总结了新的基于云原生技术的端应用研发范式,期望为广大开发者、企业提供云计算时代面向企业业务前台的应用研发方法论。
16031 0
云原生HSAP系统Hologres产品价值解读
企业拥抱数字化转型已成为行业共识,越来越多的企业加快推进数字化转型和升级,数据价值的重要性越加显著。本次分享将由阿里云计算平台-交互式分析团队产品经理李姗姗为大家进行云原生HSAP系统Hologres产品价值解读。主要分享主流实时数仓架构以及其实践的痛点,与云原生HSAP系统创新的价值。
2410 0
云原生数据库POLARDB的应用探索
某金融支付公司资深DBA赵怀刚为大家带来云原生数据库POLARDB的应用探索的介绍。内容包括为什么选择POLARDB,相比RDS、MySQL有哪些新特性和优势,以及最佳适用场景的探索和实践。
1248 0
为什么云原生应用程序是未来
鼎点网络 现在,每个人都在谈论如今在云原生态环境中构建的应用程序。什么是云原生的,为什么它如此重要? 在深入挖掘之前,可以先看看一个有趣的陈述。据调研机构IDC称,到2022年,90%的新应用都将采用微服务架构,提高设计、调试、更新和利用第三方代码的能力;所有生产应用程序的35%将是云原生的。
832 0
这本书将为你揭秘一场云原生技术革命 | 开发者必读(018期)
最炫的技术新知、最热门的大咖公开课、最有趣的开发者活动、最实用的工具干货,就在《开发者必读》!
829 0
+关注
4
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载