Categories
程式開發

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 為雲原生應用帶來哪些價值? 1

2. 平台無關、運行時無關

OAM 應用定義並不限定你底層的平台和實際運行時,你完全可以運行在 K8s 以外的平台,不管是 ECS、Docker、又或是 FaaS (Serverless),自然也不存在廠商鎖定的問題。如果你的應用滿足 Serverless 的條件,那麼針對該應用的 OAM 描述,天然就可以運行在支持 OAM 規範的 Serverless 運行時。

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 2

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

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 3

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.
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 的資源棧模板文件,最終拉起雲上的資源。

ROS 的 OAM 實現也將在不久之後開源,敬請期待!

4. 關心架構而不是基礎設施

用戶的訴求其實是應用的架構,而不是具體使用哪種基礎設施資源。

而OAM 通過“WorkloadType” 來解決這個訴求,通過描述一個應用的WorkloadType 來定義應用的架構,這個WorkloadType 可以是簡單的無狀態應用“Server”,表示應用可複制、可訪問、並作為守護進程長久運行;也可以是一個數據庫類型的應用“RDS”,對應啟動一個雲上的RDS 實例。

用戶的組件 “Component” 通過指定 “WorkloadType” 選擇具體的架構模板,多個 Component 構成了完整的架構。

使用 OAM 應用定義讓用戶真正關心的是架構,而不是具體的基礎設施。

如下圖所示,OAM 的一個應用描述,用戶指定它的應用需要一個外網訪問能力,而不是指定一個 SLB,用戶指定它的組件是數據庫的。

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 4

5. 運維能力管理

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

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

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 5

6. 透明化的集成

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

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 6

7. 不同的角色關注點分離

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

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 7

8. 彈性可擴展

OAM 應用定義是彈性、可擴展的,你可以通過擴展Workload 來定義不同類型的工作負載,你也可以通過自定義的Trait 來描述你的運維能力,而且都可以與現有的K8s 體系裡面CRD +Operator 的擴展方式完美結合。

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 8

9. 模塊化協作

OAM 通過關注點分離的思想,將應用分為研發、運維和基礎設施三個層次,同時又為研發的 Workload 和運維的 Trait 提供了模塊化協作的能力,大大提高了復用能力。

OAM 深入解讀:OAM 為雲原生應用帶來哪些價值? 9

當模塊化的Workload 和Trait 越來越多,就會形成這些組件的市場,用戶可以在CRD Registry 這樣的註冊中心,快速找到適合自己的應用的架構(Workload),以及自己需要使用的運維能力(Trait)。構建應用將越來越簡單。

未來

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

目前,阿里巴巴團隊正在上游貢獻和維護這套技術,如果大家有什麼問題或者反饋,也非常歡迎與我們在上游或者釘釘聯繫。

本文轉載自公眾號阿里巴巴雲原生(ID:Alicloudnative)。

原文鏈接

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