OAM 深刻解讀：OAM 爲雲原生應用帶來哪些價值？

做者 | 孫健波（天元）  阿里巴巴技術專家

導讀：OAM 是阿里巴巴聯合微軟在社區推出的一款用於構建和交付雲原生應用的標準規範，旨在經過全新的應用定義、運維、分發與交付模型，推進應用管理技術向「輕運維」的方向邁進，全力開啓下一代雲原生 DevOps 的技術革命。

背景

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 在其中發揮的價值。

雲原生化

• OAM 應用定義是聲明式的，即面向終態的，它的格式與 K8s 的 API 一致，能夠與 K8s 的 CRD 無縫對接，直接做爲 Custom Resource 的 Object 部署到 K8s；
• OAM 應用定義是自包含的，經過 OAM 定義的描述能夠找到包含一個應用生命週期中方方面面全部的信息。

以下圖所示，你能夠看到運行 OAM 的一個應用配置，使用 K8s 的 API spec，完整包含了一個應用方方面面的資源。

平臺無關、運行時無關

OAM 應用定義並不限定你底層的平臺和實際運行時，你徹底能夠運行在 K8s 之外的平臺，不論是 ECS、Docker、又或是 FaaS (Serverless)，天然也不存在廠商鎖定的問題。若是你的應用知足 Serverless 的條件，那麼針對該應用的 OAM 描述，自然就能夠運行在支持 OAM 規範的 Serverless 運行時。

在支持 OAM 的不一樣環境中，你即可以使用統一的應用描述，打造無差異的應用交付。就以下圖所示，對應用戶，他們只要描述統一的應用配置，即可以在不一樣的環境達到一致的應用體驗。

基礎設施即代碼

雲原生的普及很大程度上推進了基礎設施即代碼的實現，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.
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，用戶指定它的組件是數據庫的。

運維能力管理

用戶但願運維能力也是應用生命週期的一部分，而 OAM 正是如此，經過綁定 Trait，來定義一個 Component 所使用到的運維能力，從而把運維能力也加入到應用描述中，方便底層基礎設施統一管理。

以下圖所示，一個應用包含兩部分組件，一個 web 服務和一個數據庫， 數據庫組件應該具備數據備份的能力，而 web 服務則能夠被訪問、能夠彈性擴縮容。這些能力由 OAM 的解釋器（即 OAM 的實現層）統一管理，今後運維能力綁定出現衝突也再也不是煩惱。

透明化的集成

就像 Docker 鏡像解決了長久以來開發、測試、生產環境不一致同樣，統一而標準化的 OAM 應用描述也讓不一樣系統之間的集成變得透明而標準化。

不一樣的角色關注點分離

OAM 也將原先 K8s All-in-one 的複雜 API 作了必定層次的解耦，分爲應用研發（管理 Component）、應用運維（將 Component 組合並綁定 Trait 變成 AppConfig）、以及基礎設施提供方（提供 OAM 的解釋能力映射到實際的基礎設施）三大角色，不一樣角色分工協做，從而總體簡化單個角色關注的內容。使得不一樣角色能夠更聚焦更專業的作好本角色的工做。

彈性可擴展

OAM 應用定義是彈性、可擴展的，你能夠經過擴展 Workload 來定義不一樣類型的工做負載，你也能夠經過自定義的 Trait 來描述你的運維能力，並且均可以與現有的 K8s 體系裏面 CRD+Operator 的擴展方式完美結合。

模塊化協做

OAM 經過關注點分離的思想，將應用分爲研發、運維和基礎設施三個層次，同時又爲研發的 Workload 和運維的 Trait 提供了模塊化協做的能力，大大提升了複用能力。

當模塊化的 Workload 和 Trait 愈來愈多，就會造成這些組件的市場，用戶能夠在 CRD Registry 這樣的註冊中心，快速找到適合本身的應用的架構（Workload），以及本身須要使用的運維能力（Trait）。構建應用將愈來愈簡單。

將來

相信應用的構建會愈來愈簡單，基礎設施的選擇會根據用戶的架構需求自動匹配，用戶能夠真正享受到雲平臺化的紅利，快速複用已有的模塊化能力，而 OAM 也將成爲應用雲原生化的必然選擇。

目前，阿里巴巴團隊正在上游貢獻和維護這套技術，若是你們有什麼問題或者反饋，也很是歡迎與咱們在上游或者釘釘聯繫。

參與方式：

• 釘釘掃碼進入 OAM 項目中文討論羣

• 經過 Gitter 直接參與討論
• OAM 開源實現地址
• 點擊 star 一下

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」