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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范,旨在通过全新的应用定义、运维、分发与交付模型,推动应用管理技术向“轻运维”的方向迈进,全力开启下一代云原生 DevOps 的技术革命。

作者 | 孙健波(天元)  阿里巴巴技术专家

导读OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范,旨在通过全新的应用定义、运维、分发与交付模型,推动应用管理技术向“轻运维”的方向迈进,全力开启下一代云原生 DevOps 的技术革命。

背景

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 在其中发挥的价值。

云原生化

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

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

1.png

平台无关、运行时无关

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

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

3.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,用户指定它的组件是数据库的。

4.png

运维能力管理

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

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

5.png

透明化的集成

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

6.png

不同的角色关注点分离

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

7.png

弹性可扩展

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

8.png

模块化协作

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

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

未来

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

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

参与方式:

  • 钉钉扫码进入 OAM 项目中文讨论群

10.png

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
17天前
|
Cloud Native 安全 物联网
云原生技术在现代软件开发中的应用与挑战####
云原生,这一词汇如同一股强劲的科技风暴,席卷了整个信息技术领域,它不仅重塑了软件的开发模式,还引领了一场关于效率、可扩展性和弹性的深刻变革。本文旨在深入探讨云原生技术的核心概念,分析其在现代软件开发中的广泛应用,并直面伴随其发展而来的挑战,为读者勾勒出一幅既充满机遇又不乏考验的云原生技术图景。 ####
|
12天前
|
敏捷开发 Cloud Native 持续交付
云原生技术在现代企业中的应用与实践
【10月更文挑战第23天】本文将深入探讨云原生技术在现代企业中的广泛应用,并结合具体案例分析其对企业数字化转型的推动作用。我们将从云原生技术的基本原理出发,逐步揭示其在提高业务敏捷性、降低成本和增强系统可靠性方面的优势。同时,文章还将分享一系列成功实施云原生技术的企业案例,为读者提供实践中的参考和启示。最后,我们将讨论云原生技术面临的挑战及未来的发展趋势,为企业在这一领域的进一步探索提供指导。
|
13天前
|
Cloud Native 持续交付 云计算
云原生技术深度探索:构建现代化应用的基石####
【10月更文挑战第21天】 本文将深入探讨云原生技术的核心概念、关键技术及其在现代软件开发中的应用。我们将从容器化、微服务架构、持续集成/持续部署(CI/CD)、无服务器架构等关键方面展开,揭示这些技术如何共同作用,帮助企业实现高效、弹性且易于维护的应用部署与管理。通过实例分析,展现云原生技术在实际项目中的显著优势,为读者提供一套全面理解并应用云原生技术的指南。 ####
31 2
|
18天前
|
运维 Cloud Native 持续交付
云原生技术在现代IT架构中的深度应用与挑战####
【10月更文挑战第17天】 本文深入剖析了云原生技术的精髓,探讨其在现代IT架构转型中的核心作用与面临的挑战。云原生不仅是一种技术实现,更是企业数字化转型的重要推手,通过容器化、微服务、持续集成/持续部署(CI/CD)等关键要素,重塑软件开发、部署与运维模式。文章首先概述了云原生的基本原则与核心组件,随后分析了其如何促进企业敏捷性、可扩展性和资源利用率的提升,同时也指出了在安全性、复杂性管理及人才技能匹配等方面存在的挑战,并提出了相应的对策建议。 ####
54 6
|
20天前
|
运维 监控 Cloud Native
云原生技术在现代企业中的应用与挑战####
【10月更文挑战第15天】 本文深入探讨了云原生技术如何重塑企业的IT架构,并分析了其带来的机遇与面临的挑战。通过案例分析,揭示了云原生技术在提升业务敏捷性、降低运维成本方面的显著优势,同时也指出了在安全性、多云管理等方面的潜在难题,为企业决策者提供了有价值的参考。 ####
22 3
|
26天前
|
运维 Cloud Native 持续交付
云原生技术:构建现代应用的基石
【10月更文挑战第9天】在数字化转型的浪潮中,云原生技术如同一股清流,引领着企业走向更加灵活、高效的未来。本文将深入探讨云原生的核心概念,揭示其在现代应用开发与部署中的重要作用,并通过实际案例分析,展现云原生技术如何助力企业实现敏捷开发和自动化运维,最终提升业务竞争力。
74 3
|
26天前
|
运维 Kubernetes Cloud Native
云原生技术:构建现代应用的新范式
【10月更文挑战第9天】 云原生是一种通过云计算环境优化的软件开发和运行方法论,旨在最大化利用云平台的灵活性、可扩展性和弹性。本文将深入探讨云原生技术的基本原理、核心组件以及其在实际项目中的应用。我们将从Kubernetes的容器编排机制入手,逐步探讨如何通过自动化工具实现持续集成与持续部署(CI/CD),最终展示如何构建一个高效、可靠的云原生应用。
39 2
|
7天前
|
Cloud Native 安全 持续交付
云原生技术在现代软件开发中的应用与挑战####
本文深入探讨了云原生技术在现代软件开发中的广泛应用及其面临的主要挑战,旨在为开发者和企业提供实用的指导和策略。云原生技术通过其独特的架构和方法论,极大地提升了软件的可扩展性、弹性和敏捷性。然而,随着技术的不断演进,如何有效应对其在安全性、复杂性和成本控制等方面的挑战,成为了业界关注的焦点。本文将详细阐述云原生技术的核心概念、实际应用案例,并针对当前面临的主要挑战提出相应的解决策略。 ####
|
23天前
|
Cloud Native Devops 云计算
云原生技术:构建现代应用的新基石
【10月更文挑战第12天】 本文深入探讨了云原生技术的核心理念、关键技术和实践方法,揭示了其在现代应用开发和运维中的重要地位。通过分析云原生技术的发展趋势和面临的挑战,本文为读者提供了全面而深入的理解,旨在帮助读者更好地利用云原生技术构建高效、灵活和可扩展的现代应用。
34 0
|
23天前
|
Cloud Native 安全 云计算
云原生技术在现代企业中的应用与挑战
本文探讨了云原生技术在现代企业中的重要性及其应用,并分析了企业在实施过程中面临的主要挑战。通过案例分析,本文展示了如何利用云原生技术提高企业的敏捷性和弹性,同时提出了相应的解决方案和建议。

热门文章

最新文章