雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
作者 | 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 标準，是以這樣的項目很快會越來越多。
作者簡介
Andy Shi 阿裡雲進階技術專家，阿裡巴巴集團開發者布道師，常年在矽谷從事開源技術推廣，在雲平台使用和網絡基礎架構方面擁有豐富經驗。
孫健波（花名：天元） 阿裡雲技術專家，是 OAM 規範的主要制定者之一，緻力于推動雲原生應用标準化。同時也在阿裡巴巴參與大規模雲原生應用傳遞與應用管理相關工作。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-28
本文作者：Andy Shi、天元
本文來自：“dockone”，了解相關資訊可以關注“dockone”