導讀：2019 年 10 月 17 日，阿裡巴巴合夥人、阿裡雲智能基礎産品事業部總經理蔣江偉（花名：小邪）在 Qcon 上海重磅宣布，阿裡雲與微軟聯合推出開放應用模型 Open Application Model （OAM）開源項目。OAM 的願景是以标準化的方式溝通和連接配接應用開發者、運維人員、應用基礎設施，讓雲原生應用管理與傳遞變得更加簡潔，高效，并且可控。
OAM 為什麼值得關注？
關注點分離：開發者關注應用本身，運維人員關注子產品化運維能力，讓應用管理變得更輕松、應用傳遞變得更可控；
平台無關與高可擴充：應用定義與平台層實作解耦，應用描述支援任意擴充和跨環境實作；
子產品化應用運維特征：可以自由組合和支援子產品化實作的運維特征描述。
Kubernetes 項目作為容器編排領域的事實标準， 成功推動了諸如阿裡雲 Kubernetes （ACK）等雲原生服務的迅速增長。但同時我們也關注到，Kubernetes 的核心 API 資源比如 Service、Deployment 等，實際上隻是應用中的不同組成部分，并不能代表一個應用的全部。也許我們可以通過像 Helm charts 這樣的方式來嘗試表達一個可部署的應用，可一旦部署起來，實際運作的應用中卻依舊缺乏以應用為中心的限制模型。
這些問題都反映出，Kubernetes 以及雲原生技術棧需要一種以應用為中心的 API 資源來提供一個專注于應用管理的、标準的、高度一緻的模型，這個 API 資源可以代表完整運作的應用本身，而不僅僅是應用模闆或者一個應用的幾個組成部分，這就是今天阿裡雲與微軟聯合宣布推出開放應用模型 Open Application Model （OAM）的原因。
項目位址：
https://openappmodel.io OAM 項目目前由規範和實作兩部分組成
什麼是 Open Application Model？
OAM 是一個專注于描述應用的标準規範。有了這個規範，應用描述就可以徹底與基礎設施部署和管理應用的細節分開。這種關注點分離（Seperation of Conerns）的設計好處是非常明顯的。
舉個例子，在實際生産環境中，無論是 Ingress，CNI，還是 Service Mesh，這些表面看起來一緻的運維概念，在不同的 Kubernetes 叢集中可謂千差萬别。通過将應用定義與叢集的運維能力分離，我們就可以讓應用開發者更專注于應用本身的價值點，而不是”應用部署在哪“這樣的運維細節。
此外，關注點的分離讓平台架構師可以輕松地把平台的運維能力封裝成可被複用的元件，進而讓應用開發者能夠專注于将這些運維元件與代碼進行內建，進而快速、輕松地建構可信賴的應用。Open Application Model 的目标是讓簡單的應用管理變得更加輕松，讓複雜的應用傳遞變得更加可控。
一、應用元件（Components）
在 OAM 中，“應用”是由多個概念共同組合而成的。第一個概念是：應用元件（Components），它是整個應用的重要組成部分。 是以說，應用元件既可以包括應用運作所依賴的服務：比如 MySQL 資料庫，也包括應用服務本身：比如擁有多個副本的 PHP 伺服器。開發者可以把他們寫的代碼”打包“成一個應用元件，然後編寫配置檔案來描述該元件與其他服務之間的關系。
應用元件的概念，讓平台架構師能夠将應用分解成一個個可被複用的子產品，這種子產品化封裝應用組成部分的思想，代表了一種建構安全、高可擴充性應用的最佳實踐：它通過一個完全分布式的架構模型，實作了應用元件描述和實作的解耦。
二、應用部署配置檔案（Application Configuration）
而為了将這些應用元件描述變成一個真正運作起來的應用，應用運維人員會通過一個專門的、包含了所有應用元件資訊的部署配置檔案來執行個體化這個待運作的應用。 這個配置檔案本身也是 OAM 規範中的一個聲明式 API，用來讓應用運維人員能夠根據開發者或者平台送出的應用描述，執行個體化出對應的、真正運作起來的應用。
三、應用運維特征（Traits）
最後一個概念是一組應用運維特征（Traits） ，它們描述了應用在具體部署環境中的運維特征，比如應用的水準擴充的政策和 Ingress 規則，這些特征對于應用的運維來說非常重要，但它們在不同的部署環境裡卻往往有着截然不同的實作方式。
舉一個簡單例子，同樣是 Ingress，它在公有雲上和本地資料中心的實作可能是完全不同的：前者一般是 SLB 這樣的雲服務，而後者則可能是一個專門的硬體。這也就意味着針對這兩個環境的 Ingress 運維工作，将會有天壤之别。但與此同時，無論是在哪個環境裡，這個 Ingress 規則對于應用開發人員來說，可能是完全相同的。
應用特征的設計，讓這種關注點分離成為可能：隻要這兩個環境在 OAM 模型下提供了對 Ingress 這個應用運維特征的實作，那麼你的應用就可以使用統一的 Ingress 規則描述無差别的在這兩個地方運作起來。而與此同時，這兩個環境的基礎設施供應商可以繼續通過配置這些應用特征的實作，來滿足它們各自的運維要求（例如：不同環境裡 Ingress 實作在滿足合規性和安全性上的差異）。
OAM：平台無關、高可擴充的應用描述能力
與 PaaS 應用模型相比，OAM 有很多獨有的特點，其中最重要一點是：平台無關性。雖然我們目前釋出的 OAM 實作（rudr）是基于 Kubernetes 的，但 Open Application Model 與 Kubernetes 并沒有強耦合。實際上 ，OAM 可以實作到任意平台或運作環境之上，這當然也包括邊緣計算與物聯網的場景。我們也認同Kubernetes 在很多運作環境中可能并不是最好的選擇，或者是像 Serverless 這類使用者并不需要關心基礎設施複雜性的運作環境。在這些場景下，OAM 都可以提供完全一緻的應用管理體驗。
第二個重要的特點是，OAM 的 specification （OAM 規範） 在設計上天然是可擴充的。OAM 不像 PaaS 那樣自成封閉體系，也不會通過某種獨有的應用管理環境來屏蔽掉底層平台的特點（比如：在 Kubernetes 之上”蓋一個大帽子“）。 相反，OAM 使平台層可以通過應用特征系統 （Trait system）來展現平台的特性和差異性。也就是說，隻要不同的平台都能夠提供應用所需要的某些應用特征 (Trait)，開發人員就能輕松地研發跨平台的應用。類似地，哪怕最底層的硬體提供商，也可以通過應用特征系統來展現其平台特性。
OAM 的整體設計，就是為了避免在平台可移植性中經常發生的“最小公分母”鎖定問題。相反，OAM 不但提供了可移植性的能力，它還確定了每個平台有能力去透出獨有的特性和用途。OAM 讓開發人員可以自由地針對不同平台以标準方式在可移植性和差異化功能之間取得平衡。
開放的社群與未來
如今，開放應用模型以及相應的 Kubernetes 實作有了初步的成果，我們感到非常興奮。OAM 規範是基于 Open Web Foundation 協定進行開發的。我們的目标，從一開始就是讓開放應用模型 Open Application Model 成為中立基金會的項目，以便實作開放治理與廣泛合作。
如果您想了解更多資訊，請前往開放應用模型項目的GitHub 倉庫：OAM specification，以及基于 Kubernetes 的 OAM 标準實作 Rudr 。
OAM Specification 位址，點選
這裡Rudr 位址，點選
今天 OAM 項目的釋出隻是邁出的一小步。我們非常期待得到您的回報，并與大家密切協作，針對 Kubernetes 和任意雲環境打造一個簡單、可移植、可複用的應用模型。