2019 年 10 月 17 日上午 9 點 15 分，阿里巴巴合夥人、阿里雲智能基礎產品事業部總經理蔣江偉在 QCon 上海《基於雲架構的研發模式演進》主題演講中，正式宣佈：
“今天，我們同微軟聯合發佈了一個全新的項目，叫做開放應用模型 Open Application Model（OAM）。”
項目主頁：https://openappmodel.io
蔣江偉在發佈中講道：“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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆號。”
搜索「阿里巴巴雲原生公衆號」獲取更多K8s容器技術內容