OAM存在的意義是什么

今天就跟大家聊聊有關OAM存在的意義是什么，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

OAM Kubernetes Runtime 將會成為 OAM 社區官方維護的基礎組件，目標是在 Kubernetes 上提供穩定且統一的 OAM 核心插件。 

為進一步了解，本次探討了 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存在的意義是什么有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。