今年 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 標準，所以這樣的項目很快會越來越多。