2019 年 10 月 17 日上午 9 點 15 分，阿裡巴巴合夥人、阿裡雲智能基礎産品事業部總經理蔣江偉在 QCon 上海《基于雲架構的研發模式演進》主題演講中，正式宣布：
“今天，我們同微軟聯合釋出了一個全新的項目，叫做開放應用模型 Open Application Model（OAM）。”
項目首頁： https://oam.dev/
蔣江偉在釋出中講道：“OAM 這個項目是業界第一個雲原生應用标準定義與架構模型。我們希望通過這樣的架構模型，以高效、标準的方式連接配接應用開發者、運維人員和應用的最終使用者，讓這些雲端應用的參與者能夠享受到像智能手機上一樣簡單、輕松、暢快的應用管理體驗。”
與此同一時間，微軟傑出工程師（Distinguished Engineer） 、Kubernetes 項目創始人 Brendan Burns 也在微軟的官方網站上，宣布了同阿裡雲的這次重量級聯合釋出。
圖檔來源：
https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-open-application-model/你可能會好奇，到底什麼是 OAM 呢？又是什麼原因，讓兩家全球頂級技術公司走在一起，希望聯合整個雲原生技術社群共同推進這樣一個應用定義與架構模型項目呢？
這個事情本身，可能要從世界上最早的一次雲端應用傳遞的故事講起。
一個雲端應用傳遞的故事
2006 年 3 月 14 日，美國某線上電商公司釋出了一個叫做 Simple Storage Service（簡稱 S3）的存儲服務。在這個服務釋出不久，一名來自微軟的技術人員帶着嘗鮮的想法，編寫了一個使用該服務作為底層存儲的應用。據這位開發者講述，從決定編寫應用到将該應用傳遞運作“總共花掉了幾天的時間”。對此，他感到非常興奮，後來他在自己的部落格裡這麼寫到：
“這個服務的釋出，徹底改變了技術行業的遊戲規則”。
這位開發者的名字，叫做 James Hamilton 。他是 IBM DB2 早期的架構師，也是當時 Microsoft SQLServer 的負責人之一。就在編寫完這個神奇的應用兩年後，他選擇加入了這家電商公司。如今，James Hamilton 已經成為了 AWS 的副總裁（VP）和标志性人物。
從 2006 年到現在，雲計算經曆了一波又一波變革和浪潮。如今的雲，早已不再是 13 年前那個大衆眼裡需要“嘗鮮”的陌生事物。如今的雲服務，也早已在一次次的變革之中脫胎換骨，在成本和資源效率的極緻優化中，将“摩爾定律”的失效推上了頂峰。2019 年 8 月，阿裡雲驕傲的向全世界宣布，雲計算“拐點已至”。上雲，正迅速成為企業進行應用架構和基礎設施規劃的預設選項。
在 2019 年，如果一位開發者要像 James 當年一樣，把一個 Java Web 網站在雲平台上線，到底體驗如何呢？
雲端應用管理的兩大難題
在回答上面的問題之前，我們不妨先思考一下：現如今在智能手機上安裝一個應用，是什麼樣的體驗？更新應用呢？
在以 iPhone 為代表的智能手機上，應用管理的體驗實際上是一個“如絲般順滑”的感受。
現在，我們再回過頭來看雲。
一個雲上的應用，肯定不隻是簡單的可執行檔案。就拿 Java Web 網站為例，這個應用要想在雲平台上被最終使用者使用到，就需要有大量的外部依賴需要處理。這就是雲端應用開發者實際上關心的事情，其實一點也不簡單：
這種情況下，在雲上傳遞一個應用的過程，實際上非常坎坷。
舉幾個例子：作為雲上的開發者，我們首先需要花費大量的時間來進行應用整體部署架構的設計，才能大緻搞清楚這個應用到底需要開通哪些雲服務。但這依然避免不了一些讓人頭疼情況的發生，例如：
- 因為一個操作流程失誤，一些需要預先申請的雲資源不到位，就得返工重來；
- 一旦某個雲服務的配置不合理，就得重新配置，甚至删掉重來；
- 整個上線應用的過程，我們需要不停地在各種雲産品控制台之間來回跳轉；
- 還有很多時候，我們不得不一個一個手工處理應用删除遺留下來的各種雲資源。
上述情況的出現，總的來說是因為雲上應用管理的過程，實際上是一個離散的狀态，導緻整個流程雜亂無序，也很難把控，出錯返工就在所難免了。
再舉個例子。除了過程上的繁雜之外，雲端應用管理的另一個現狀就是：開發者總是需要不停的去開通和配置各種各樣的雲服務，同時也要花大量的時間去開發各種雲産品的開通和接入代碼。尤其讓人頭疼的是，這些所有對雲服務的開通、配置和接入工作，幾乎都是“一次性工作”。我給一個應用元件做的事情，再上線另一個應用元件的時候，又得全部重新做一遍。甚至有時候為了接入一個新的雲服務，必須重新開發整個應用。上述情況的出現，歸根到底是因為對于應用所依賴的雲服務來說，它們的開通與配置工作，并不是一個可複用的能力，這就導緻了大量的重複勞動和對接工作需要一而再、再而三的在應用管理的過程中不斷重複進行。
這些情況，都是現今制約和困擾着雲端應用開發和運維人員的幾個典型“症狀”，也點明了目前雲應用管理過程“耗時”、“耗力”背後，兩個顯著的症結所在：
- 應用本身：不能以統一、自描述的方式定義應用與雲資源的關系；
- 雲基礎設施本身：沒有一種統一、标準、高效的方式傳遞給應用使用。
智能手機 VS 雲
在體驗到了手機上 App 管理的流暢和簡單之後，現在再來看雲端應用管理的卡頓和繁雜，我們不禁會想到這樣一個問題：雲計算技術日新月異的今天，我們是否有機會在雲上也感受到像智能手機一樣的應用管理體驗呢？
事實上，如果我們深入分析一下智能手機上的應用管理體系和如今的雲端應用管理架構，就會發現，這兩者本質上是完全一緻的**。
首先，在标準的硬體，或者說手機的“标準化基礎設施”之上，智能手機已經為使用者鋪上了一個“标準化的接入層”。**在 iPhone 上，這個标準化接入層，就是 iOS 作業系統，它對上暴露出 UNIX 風格的作業系統接口來屏蔽掉底層資源的細節。在雲上，這一層實際上就是 Kubernetes 和雲服務本身的 OpenAPI。
但，這顯然還不是全部。
無論是應用開發者還是 APP 最終使用者，我們還是不會直接跟 UNIX 作業系統接口打交道。這是因為，在“标準化的接入層”之上，iPhone 還為使用者提供了一整套的“标準化應用架構與管理體系”。這套體系，既包括了對作業系統接口的 Library 化封裝（即：子產品化的 SDK），也包括應用如何組織和打包的傳遞規範，還以此為基礎，提供了 IDE 等一系列開發工具甚至程式設計語言。這才使得基于 iOS 之上的應用管理，呈現出了“如絲般順滑”的使用者體驗。
這時候，我們再回過頭來看雲計算。就會發現：在對應“标準化的應用架構與管理體系”這一層，雲的能力目前是缺失的。雲上的應用，并沒有一種統一和标準的方式來描述自己與雲資源的關系，也沒有一種統一和标準的方式來對接雲計算的基礎設施服務**。
這也是為什麼在 2006 年，一位開發者上線世界上最早的 S3 應用，隻需要花費幾天的時間，然而 13 年後，當雲計算提供的能力已經強大到天壤之别的今天，我們在雲上傳遞和更新一個 Java Web 網站，卻恐怕還是要花費數小時之久，甚至更長。
什麼是 OAM？
開放雲應用模型 Open Application Model（OAM），它正是一個雲原生時代的應用标準定義與架構模型。Open Application Model 的主要内容，就是為雲端應用管理者提供了一套描述應用的規範。應用管理者隻要遵守這個規範，就可以編寫出一個自包含、自描述的“應用定義檔案”。具體的說，這個應用定義檔案實際上由兩部分組成：
應用描述 = 應用元件 + 應用特征
應用元件：應用開發者通過一個聲明式的描述，來定義他要部署和管理的是什麼樣的應用。比如，是 Java Web 網站？是容器？還是 Function？這個應用怎麼運作，是通過 Kubernetes ？還是 ECS？需要注意的是，這個應用描述，是對應用本身開發和運作方式的、一個開發人員視角的叙述，它不會包括任何應用運維和基礎設施相關的細節。
應用特征：應用運維人員則通過另一個聲明式的描述，來定義這個應用的“運維特征”。比如，安全組政策怎麼設定？路由通路政策是什麼規則？水準擴充政策如何？可以看到，這些應用特征，實際上是對應用運維細節和基礎設施能力的叙述。
是以說，在 OAM 規範下，在雲上管理一個應用，實際上是通過這樣兩個聲明式的描述配合來完成的。在實際操作中，應用開發人員隻需要送出他所編寫的應用描述，運維人員則負責定義和管理各種各樣的應用特征。雲平台或者應用架構師，則負責按照應用描述中的需求，為它綁定合适的應用特征。
而 OAM 這套規範的特殊性在于，它并不是一套“應用配置 + 外部依賴 ”的簡單組合，而是在應用定義的規範中，“植入”了對雲端應用管理至關重要的兩個“解耦”：
- 第一，應用管理過程中的角色解耦。 通過這個解耦，OAM 應用管理流程中開發和運維角色就可以各司其職，隻關注自己關心的部分，這是 OAM 提升開發者生産力的重要途徑。而與此同時，雲平台或應用架構師，則可以靈活的組合應用特征和應用描述，進而在完全不影響開發人員體驗的情況下，為雲上的應用搭配合适的應用特征。這種關注點分離（Seperate Conerns）的設計，使得 OAM 模型下的應用的定義，不僅職責明确，同時也能清晰的自描述出一個應用所依賴的所有雲基礎設施能力（即：特征），并為對它們的關系進行系統化管理提供了基礎。
- 第二，應用定義與實作層解耦。通過這個解耦，使用者的應用定義和雲的基礎設施能力是完全分開的。是以一個應用，不會再被局限于隻能運作某種具體的平台或者雲服務上：對于這些應用運作時的選擇，隻是應用描述中的一個可配置參數而已。而應用的運維特征，在實作層實際上就是每一個雲基礎設施能力的子產品化實作。是以一旦一個應用描述與某個應用特征綁定，雲平台就可以自動将對應的雲服務接入到應用運作時當中，進而避免了使用者陷入到“永無止境”的雲服務開通和配置工作中。
不過，OAM 對于雲端應用管理的價值，還遠遠不止更好的使用者體驗這麼簡單。
應用特征系統：平衡可移植性和差異性
在 Open Application Model 的模型中，應用管理人員可以靈活搭配應用描述與應用特征，進而對接不同的雲基礎設施能力到應用中。這種基礎設施能力通過 OAM 對使用者透出之後，實際上就能夠差異化的表達不同運作環境能夠為應用提供的不同基礎設施能力。
舉個例子，一位開發者定義了一個叫做“車”的應用描述，并做出了如下叙述：
- 要有安全性
- 要能有操控能力
- 要有行使動力
然後，他把這樣的應用描述交給了雲平台，雲平台根據這個描述，為它綁定了一組比較基礎的“應用特征”：
- 安全：安全帶、氣囊、普通刹車
- 操控：手動 5 檔、普通方向盤
- 動力：普通發動機
這樣，這個應用在它的最終使用者看來，實際上就是一個“家用汽車”。
但是，過了一陣子，開發者決定對這個“車”進行一次更新。這時候，他該怎麼做呢？
實際上，他什麼也不用做。他隻要告訴應用運維，為之前的“車”應用描述，綁定一組更加“強大”的應用特征即可，比如：
- 安全：高強度車架、懸挂減震、全身防護、賽車式刹車
- 操控：手動 8 檔、賽車方向盤
- 動力：賽車引擎
是以，一旦上述“更強大”的應用特征，同“車”應用描述綁定，我們就可以将一個“家用車”立刻更新成一部強大的“賽車”。而在這個過程中，應用開發和應用運維唯一要做的事情，就是像“樂高積木”那樣，靈活搭配群組裝不同的應用特征而已。
而更重要的是，OAM 的設計初衷之一，是要提供标準化雲端應用管理體驗，這就需要“抹平”不同運作環境之間的不同，以便讓應用“ 一次定義，多處運作”。但與此同時，OAM 提供的應用特征系統，則使得雲平台标準化的暴露出自己的能力之後，使用者依然可以通過對比不同運作環境的應用特征的差異，進而更準确的選擇自己的應用要部署到哪個運作環境當中，真正意義上實作“Define Once, Run Where I Choose” 的傳遞體驗。是以說，應用特征系統，正是 OAM 在設計中平衡可移植性和差異性的一個重要的創新之舉。
OAM 項目的現狀與未來
OAM 開源項目，主要包括了兩部分内容：
- Open Application Model Specification （OAM Spec）：這個項目是 OAM 模型的官方規範與标準庫。在這個代碼庫中，詳細的闡述和定義了 OAM 模型中的所有核心理念和詳細到具體字段的 API 規範。與此同時，這些所有的 Spec 也都原生提供了進一步的擴充規範，使得這個模型本身具備了接入任意運作時、子產品化任意雲基礎設施能力、标準化描述任意應用運維特征的、高靈活度的模型限制力。可以看到，這個庫堪稱 OAM 的使用者和實作者的官方“聖經”。
OAM Spec 項目 GitHub 位址： https://github.com/oam-dev/spec
- Rudr 項目: 這個項目，是 Open Application Model 在 Kubernetes 上的标準實作。Rudr 項目本身是 Kubernetes 的一個标準插件，隻要安裝上去即可為使用者提供标準的 OAM 風格的的應用管理能力，通過子產品化應用特征同 SMI，Knative，Istio 等應用基礎設施能力無縫對接。值得一提的是，Rudr 項目是由 Rust 編寫完成的，它的實作簡潔、高效，性能優異，也是全世界第一個 Rust 實作的 Kubernetes 生态開源元件。
Rudr 項目 GitHub 位址： https://github.com/oam-dev/rudr
雖然 OAM Spec 和 Rudr 項目目前是由阿裡雲和微軟雲的工程師共同發起和維護的，但這兩個項目本身，均從一開始就采用中立基金會的方式進行運作，使用完全中立和開放的開源貢獻者協定，同任何一家公司或者組織都沒有綁定關系。這麼做的原因也非常明朗：作為未來雲計算應用管理生态的基礎性模型，Open Application Model 從一開始就采用完全中立和開放的方式同整個社群協作，并計劃在項目穩定後便移交給中立基金會進行托管。
目前，OAM 已經在阿裡雲多個項目中進行了數月的内部落地的嘗試。通過一套統一、标準的應用定義體系，承載了多個雲應用管理項目和産品的應用與外部資源關系的高效管理，并将雲原生應用管理體驗統一的帶給了基于 Function、ECS、Kubernetes 等不同運作時的應用管理流程；通過應用特征系統，将多個阿裡雲獨有的能力進行了子產品化，大大提高了阿裡雲基礎設施能力的傳遞效率。
與此同時，作為 OAM 的初創參與方，微軟 Service Fabric 團隊已經開始通過 OAM 模型将 Service Fabric 強大的應用基礎設施能力進行了“樂高積木化”，進而無縫接入到雲原生技術體系當中，并進一步在此基礎上開始了“Mesh 化程式設計模型”的建構。
在未來的發展過程中，OAM 将會始終緻力為雲應用管理的參與者帶來智能手機一般的使用體驗，在保證可移植性和可擴充性的前提下，以标準化的方式幫助“應用”高效和高品質地傳遞到世界上任何一個位置。我們期待全世界每一位開發者和每一個雲計算生态的參與者，都能加入到這個全新的應用架構模型的發展過程中來，共同打造一個繁榮的雲端應用生态背後的标準模型和基礎依賴。
“ 阿裡巴巴雲原生微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”