作者 | Andy Shi（阿里雲高階技術專家）、天元（阿里雲技術專家）

今年 5 月，阿里雲和微軟雲共同宣佈， Open Application Model （OAM）社群攜手知名混合雲管理專案 Crossplane 社群，聯合釋出了 OAM 在 Kubernetes 平臺上的標準實現與核心依賴庫。本次合作達成後，OAM 社群成功的將標準應用定義和標準化的雲服務管理能力統一起來，邁出了實現真正意義上的無差別雲端應用交付的關鍵一步。

去年 10 月，阿里雲和微軟共同推出了 OAM 專案，旨在構建圍繞 Kubernetes 的雲原生應用規範。OAM 描述了一個模型 —— 開發人員可以在其中定義應用程式元件；應用程式操作員負責建立這些元件的例項併為它們分配應用程式配置；基礎架構運營商負責定義、安裝和維護平臺上可用的基礎服務。

本次合作是阿里雲、微軟與 Crossplane 社群的三方技術合作，主要圍繞 OAM 在 Kubernetes 上的標準實現以及 Crossplane 專案的 OAM 化展開。因為 Kubernetes 社群在落地 OAM 模型的過程中，提出了關於 OAM 標準實現的訴求。所以這次合作的一個重點，就是三方工程師使用 Go 語言開發了一個 OAM Kubernetes 核心依賴庫。這個專案的名字叫做 oam-kubernetes-runtime。OAM Kubernetes Runtime 將會成為 OAM 社群官方維護的基礎元件，目標是在 Kubernetes 上提供穩定且統一的 OAM 核心外掛。

為進一步瞭解本次合作的細節以及 OAM 專案的現狀，阿里雲高階技術專家 Andy Shi 以及阿里雲技術專家孫健波（花名：天元）接受開源中國的專訪，共同探討了 OAM 專案存在的意義。

詳情戳：

OAM 因何而生

我們知道，應用容器技術自誕生開始，就以 “徹底改變了軟體打包與分發方式” 的魅力迅速征服了幾乎所有的雲廠商與資料中心。不過，軟體打包與分發方式的革新，並沒有能夠讓軟體本身的定義與描述發生本質的變化，基於 K8s 的應用管理體驗，也沒有讓業務研發與運維的工作變得更簡單。

實際上，Kubernetes 帶來的雲原生技術革命，在於實現了基礎設施層的標準化和抽象，但這一層抽象距離業務研發與運維還是太過遙遠了。一個最典型的例子，直到今天，Kubernetes 裡面始終都沒有 “應用” 這個概念，它提供的是更細粒度的 “工作負載” 原語，比如 Deployment 或者 DaemonSet。

而在實際環境中，一個應用往往是由一系列獨立元件的組合，比如一個 “PHP 應用容器” 和一個 “資料庫例項” 組成的電商網站；一個 “引數服務節點” 和一個 “工作節點” 組成的機器學習訓練任務；一個由 “Deployment + StatefulSet + HPA + Service + Ingress” 組成的微服務應用。

“應用” 這個概念在 Kubernetes 專案中的缺失，既是一個有意而為之的設計，卻也造成了今天雲原生應用管理生態的極度碎片化和極高的學習門檻。如何透過標準化的方式去解決這個 “Kubernetes 裡到底什麼是應用” 的問題，正是 OAM 專案釋出的最初始動機。

有什麼意義？

在 OAM 釋出之前，雲原生生態裡其實並沒有一個叫做 “應用” 的概念。哪怕在今天，全世界幾乎每一個在落地雲原生的團隊，都有一個自己定義的 “應用” 的概念，它們的抽象程度層次不齊，定義方式也豐富多樣，這就導致了所有圍繞著這些 “應用” 構建出來的系統，就成為了一個又一個的大煙囪。

對於整個雲原生生態來說，這種應用層的碎片化和煙囪化，其實對於整個生態演進是非常不利的。而今天的現狀也已經證明了這一點，在 Kubernetes 逐漸標準化了基礎設施能力的接入方式之後，原本更加接近使用者、更加重要的應用管理層，卻幾乎停滯了演進，在最近幾年裡沒有提出任何一個創新性的思想出來。

應用管理層停滯不前的結果，就是全世界的業務研發和運維一夜之間都被迫變成了 “容器專家”，一邊學習著根本不應該是他們關心的各種 “基礎設施即資料（Infrastructure as Data）” 領域的概念（比如：宣告式 API，控制器等），一邊吐槽 Kubernetes 實在是太複雜了、設計太奇葩了。

簡而言之，Kubernetes 作為一個面向基礎設施工程師的系統級專案，主要負責提供松耦合的基礎設施語義，這就使得使用者學習和操作 Kubernetes YAML 檔案的時候，往往會感覺這些檔案裡的關注點非常底層，學習門檻很高。

實際上，對於Kubernetes 真正的終端使用者比如業務研發人員和運維人員來說，他們並不想配置這些如此底層的資源資訊，而是希望有更高維度的抽象。這就要求一個真正面向終端使用者側的應用定義，需要能夠為業務研發和應用運維人員提供各自視角的應用定義原語。所以說，OAM 帶來的第一個改變，就是提供了一種大家都可以遵循的、標準化的方式來定義更高層級的應用層抽象，並且把“關注點分離”作為這個定義模型的核心思想。

而 OAM 帶來的第二個變化，則是為 Kubernetes 專案帶來了應用定義，更確切地說，是對應用本身和它所需運維能力進行定義與描述的標準開源規範。站在 Kubernetes 專案的角度來講，OAM 是一個 Kubernetes 原生的標準的“應用定義”專案，同時也是一個專注於封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連線“運維能力”與“應用”的平臺層框架。

詳細的說，OAM 基於 Kubernetes API 資源模型（Kubernetes Resource Model）來標準化應用定義的規範，它強調一個現代應用是多個元件的集合，而非一個簡單的工作負載或者 K8s Operator。所以在 OAM 的語境中，一個 PHP 容器和它所依賴的資料庫，以及它所需要使用的各種雲服務，都是一個“電商網站”應用的組成部分。更進一步的，OAM 把這個應用所需的“運維策略”也認為是一個應用的一部分，比如這個 PHP 容器所需的 HPA（水平自動擴充套件策略）：

以 Crossplane 專案為例，它在本次合作中透過 OAM 升級之後得到了怎樣的變化呢？

“ 作為混合雲管理領域中的佼佼者，Crossplane 的 OAM 化保證了今天任何一個符合 OAM 規範的待執行程式、運維能力和它所依賴的雲服務，可以組成一個整體在混合雲環境中無縫漂移。”

這種平臺無關的應用定義正規化，使得應用研發人員只需要透過 OAM 規範來描述他們的應用程式，那麼該應用程式就可以在任何 Kubernetes 群集或者 Serverless 應用平臺甚至邊緣環境上執行，而無需對應用描述做任何修改。本次合作中 Crossplane OAM 版的釋出，則意味著 OAM 社群正在將標準應用定義和標準化的雲服務管理能力統一起來，從而實現真正的 “雲端應用交付” 。

OAM 如何發揮作用？

那麼 OAM 在一個專案中是如何運作的呢？

據介紹，OAM 以原生外掛的方式執行在 Kubernetes 當中。OAM 強調整個模型是關注點分離的。即業務研發人員負責定義和維護元件 (Component) 來描述服務單元，而運維人員定義運維特徵 (Trait)，並將其附加到前面的元件上，最後構成 OAM 可交付物 ——ApplicationConfiguration。

這種設計是 OAM 在能夠無限接入 Kubernetes 各種能力的同時，保證給業務研發與運維人員提供最佳的使用體驗和最低的心智負擔的重要基礎。與此同時，基礎設施工程師可以隨時在 Kubernetes 中新增更多工作負載（例如 FaaS）以執行無伺服器功能，或者新增運維特性（例如 CronHPA）來定義 CronJob 型別的 HPA 策略。OAM 以標準的宣告方式在整個平臺中管理應用交付能力和流程，並且提供面向各個角色的 API 原語來表達各自的訴求，最後透過 Kubernetes 把這些訴求落實。

什麼樣的專案需要 OAM？

實際上，幾乎所有基於 Kubernetes 的應用管理平臺都對透過 OAM 來以標準化的方式去構建自己的應用模型有明確的訴求。另一方面，由於 OAM 是原生的 Kubernetes API 資源模型，這裡的遷移過程難度很低，可以透過 API 物件灰度納管的方式逐步完成遷移操作（透過 OAM 物件逐步接管現有 Kubernetes 物件）。

而相比於傳統 PaaS 封閉的、不能同 “以 Operator 為基礎的雲原生生態” 銜接的現狀，基於 OAM 和 Kubernetes 構建的現代雲原生應用管理平臺，本質上是一個 “以應用為中心” 的 Kubernetes ，保證了這個應用平臺在能夠無縫接入整個雲原生生態。同時，OAM 可以進一步遮蔽掉容器基礎設施的複雜性和差異性，為平臺的使用者帶來低心智負擔的、標準化的、一致的應用管理與交付體驗。這就使得一個基於OAM 構建的 Kubernetes 應用平臺，首先能夠隱藏底層基礎設施的細節（例如，是雲還是物聯網），專注於應用層抽象，提供以應用為中心的資源模型。

其次，OAM 劃分了應用交付路徑上的開發、運維、基礎架構三種角色，分離了關注點，讓流程更加清晰和易於管理。

第三，OAM 站在 K8s API 資源模型的肩膀之上，提供了可移植的應用與基礎設施抽象，讓一個應用描述可以完全不加修改的雲、邊、端等任何環境下直接交付執行起來。

除此之外，OAM 還定義了一組核心工作負載/運維特徵/應用範疇，作為應用程式交付平臺的基石。而平臺開發者也可以新增更多工作負載（例如 FaaS 或者任意雲服務），或者新增運維特性（例如 CronHPA）來定義 CronJob 型別的 HPA 策略。OAM 以標準的宣告方式在整個平臺中管理應用交付能力和流程。當模組化的 Workload 和 Trait 越來越多，就會形成元件市場。而 OAM 就像是這個元件市場的管理者，處理元件之間的關係，把許多元件整合起來變成一個產品交付給使用者。OAM 加持下的 Kubernetes 應用管理平臺，可以像樂高積木一樣靈活組裝底層能力、運維特徵、以及開發元件。使得應用管理變得統一，功能卻更加強大。

OAM 社群現狀

談到 OAM 專案社群的現狀。“ 作為一個沒有同商業訴求繫結的中立開源社群，OAM 生態自成立以來保持著較高的活躍度和參與度，大量的社群 Issue/PR貢獻都來自阿里和微軟之外的團隊比如 AWS、騰訊、位元組跳動、諧雲、青雲、好雨雲、第四正規化等生態參與者。除了阿里和微軟本身以及基於 OAM 實現了內部應用管理架構的統一和標準化之外，不少基於 OAM 的雲服務比如阿里雲 EDAS 也已經上線。”

與此同時，OAM 技術體系也開始在很多大型社群使用者（比如 MasterCard 萬事達卡）中落地，同時也出現了產品和商業化的實踐（比如：諧雲的視覺化OAM實現），甚至來自其它雲廠商比如 AWS 的開源專案整合與對接。可以看到，OAM 社群正在迅速成長和壯大中。

開源社群的運作模式一直是我們比較好奇的地方。據介紹，OAM 專案目前完全由社群驅動，由各子專案的 Maintainer 小組進行維護和管理。社群有每兩週一次的社群會議（美國和北京時間各一個）來進行重大事項的討論與決策和同步專案進度。整個社群的的工作流程按照 Maintainer 席位的投票機制來運轉，同時兼顧終端使用者的投票權。目前 OAM 社群的核心 Maintainer 來自阿里雲，微軟和 Crossplane 專案原有的成員。在推廣策略上，由多個國際化大廠團隊維護的 OAM 專案從誕生起就是完全面向國際化開源社群的運作方式，憑藉阿里與微軟自身場景，以及整個雲原生社群和貢獻者的高質量輸入來驅動整個專案向正確的方向持續演進，在溝通、分享、協作的氛圍中鼓勵貢獻和發展社群。這種模式下，一旦突破早期破冰階段，在隨後社群傳播和推廣方面會帶來病毒式的效果。

目前 OAM 的版本是 v1alpha2 ，OAM 的版本之後會不停迭代，根據實際的場景持續演進；當然，同時 spec 本身也會保證規範的穩定和相容。這個標準的更新速度主要是取決於使用者的接受程度和反饋的情況，並且會在今年釋出 Beta 版。本次合作中，OAM 已經發布了 Kubernetes 的標準實現與核心依賴庫，這也就意味著未來整個開源生態都可以直接透過對接 Crossplane 或者 oam-kubernetes-runtime 來支援 OAM 標準，所以這樣的專案很快會越來越多。

如果你有任何疑問：
釘釘掃碼進入 OAM 專案中文討論群

作者簡介

Andy Shi 阿里雲高階技術專家，阿里巴巴集團開發者佈道師，常年在矽谷從事開源技術推廣，在雲平臺使用和網路基礎架構方面擁有豐富經驗。

孫健波（花名：天元）阿里雲技術專家，是 OAM 規範的主要制定者之一，致力於推動雲原生應用標準化。同時也在阿里巴巴參與大規模雲原生應用交付與應用管理相關工作。

課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲端計算的新正規化——Serverless。

點選即可免費觀看課程： https://developer.aliyun.com/learning/roadmap/serverless

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

OAM 創始團隊：揭秘 OAM Kubernetes 實現核心原理