阿里簡介：全球首個云原生應用標準定義和架構模型開放應用模型(OAM)開源項目，由阿里云和微軟聯合推出。今日，阿里巴巴合伙人、阿里云智能基礎產品事業部總經理蔣(花名：)在滬發布重磅消息。OAM的愿景是以標準化的方式溝通連接應用開發者、運維人員、應用基礎設施，讓云原生應用管理和交付變得更加簡潔高效。
2019年10月17日上午9:15，阿里巴巴合伙人、阿里云智能基礎產品事業部總經理蔣在上海《基于云架構的研發模式演進》主題演講中正式宣布：
“今天，我們和微軟聯合發布了一個全新的項目，叫做開放應用模型(OAM)。”
項目主頁：https://openappmodel.io
姜偉在發布中表示：“OAM是業界首個云原生應用標準定義和架構模型。我們希望通過這樣的架構模型，將應用開發者、運維人員和應用的最終用戶以高效、標準的方式連接起來，讓這些云應用的參與者享受到智能手機上一樣簡單、輕松、無憂的應用管理體驗。”
與此同時，微軟杰出工程師、Kubernetes項目創始人布倫丹伯恩斯(Brendan Burns)也在微軟官網宣布了這一與阿里云的重量級聯合發布。
圖像來源：
https://cloud blogs . Microsoft . com/open source/2019/10/16/announcing-open-application-model/
你可能很好奇，OAM到底是什么？是什么原因讓兩家全球頂尖的技術公司走到一起，希望聯合整個云原生技術社區，共同推動這樣一個應用定義和架構模型項目？
事情本身可能要從世界上最早的云應用交付的故事說起。
一個云端應用交付的故事
2006年3月14日，美國一家在線電子商務公司發布了一項名為簡單存儲服務(Simple Storage Service，簡稱S3)的存儲服務。該服務發布后不久，微軟的一名技術人員抱著早期采用者的想法，編寫了一個使用該服務作為底層存儲的應用程序。據這位開發者稱，從決定編寫應用程序到將其投入運行，總共花了“幾天時間”。他對此非常興奮，后來他在博客中寫道：
“這個服務的發布，徹底改變了技術行業的游戲規則”。
這個開發者的名字叫詹姆斯漢密爾頓。他是IBM DB2的早期架構師，也是當時微軟SQLServer的領導者之一。就在寫下這份驚艷的申請兩年后，他選擇加入了這家電商公司。如今，詹姆斯漢密爾頓已經成為AWS的副總裁(VP)和標志性人物。
從2006年到現在，云計算經歷了一波又一波的變革和浪潮。如今的云，在13年前的大眾眼中，已經不再陌生。今天的云服務已經被一次又一次的改造。在成本和資源效率的極端優化中，摩爾定律的失效被推到了頂峰。2019年8月，阿里云自豪地向世界宣布，云計算的拐點已經到來。云正迅速成為企業規劃應用架構和基礎設施的默認選項。
2019年，如果一個開發者想像詹姆斯當年那樣，把一個Java網站放到云平臺上上線，是怎樣的體驗？
云端應用管理的兩大難題
在回答上面的問題之前，我們先思考一下：現如今在智能手機上安裝一個app是一種怎樣的體驗？升級應用程序怎么辦？
在以iPhone為代表的智能手機上，應用管理的體驗其實是一種“絲滑”的感覺。
現在，讓我們回到云上。
云上的應用絕對不只是簡單的可執行文件。以Java網站為例。如果這個應用程序要被云平臺上的最終用戶使用，它需要處理大量的外部依賴。這才是云應用開發者真正關心的。事實上，這一點也不簡單：
在這種情況下，在云上交付應用程序的過程實際上非常坎坷。
舉幾個例子：作為云上的開發者，我們首先需要花很多時間來設計應用程序的整體部署架構。
能大致搞清楚這個應用到底需要開通哪些云服務。但這依然避免不了一些讓人頭疼情況的發生，例如：因為一個操作流程失誤，一些需要預先申請的云資源不到位，就得返工重來；一旦某個云服務的配置不合理，就得重新配置，甚至刪掉重來；整個上線應用的過程，我們需要不停地在各種云產品控制臺之間來回跳轉；還有很多時候，我們不得不一個一個手工處理應用刪除遺留下來的各種云資源。
上述情況的出現，總的來說是因為云上應用管理的過程，實際上是一個離散的狀態，導致整個流程雜亂無序，也很難把控，出錯返工就在所難免了。
再舉個例子。除了過程上的繁雜之外，云端應用管理的另一個現狀就是：開發者總是需要不停的去開通和配置各種各樣的云服務，同時也要花大量的時間去開發各種云產品的開通和接入代碼。尤其讓人頭疼的是，這些所有對云服務的開通、配置和接入工作，幾乎都是“一次性工作”。我給一個應用組件做的事情，再上線另一個應用組件的時候，又得全部重新做一遍。甚至有時候為了接入一個新的云服務，必須重新開發整個應用。上述情況的出現，歸根到底是因為對于應用所依賴的云服務來說，它們的開通與配置工作，并不是一個可復用的能力，這就導致了大量的重復勞動和對接工作需要一而再、再而三的在應用管理的過程中不斷重復進行。
這些情況，都是現今制約和困擾著云端應用開發和運維人員的幾個典型“癥狀”，也點明了當前云應用管理過程“耗時”、“耗力”背后，兩個顯著的癥結所在：
應用本身：不能以統一、自描述的方式定義應用與云資源的關系；云基礎設施本身：沒有一種統一、標準、高效的方式交付給應用使用。
智能手機 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 這套規范的特殊性在于，它并不是一套“應用配置 + 外部依賴 ”的簡單組合，而是在應用定義的規范中，“植入”了對云端應用管理至關重要的兩個“解耦”：
1）應用管理過程中的角色解耦。通過這個解耦，OAM 應用管理流程中開發和運維角色就可以各司其職，只關注自己關心的部分，這是 OAM 提升開發者生產力的重要途徑。而與此同時，云平臺或應用架構師，則可以靈活的組合應用特征和應用描述，從而在完全不影響開發人員體驗的情況下，為云上的應用搭配合適的應用特征。這種關注點分離（Seperate Conerns）的設計，使得 OAM 模型下的應用的定義，不僅職責明確，同時也能清晰的自描述出一個應用所依賴的所有云基礎設施能力（即：特征），并為對它們的關系進行系統化管理提供了基礎。
2）應用定義與實現層解耦。通過這個解耦，用戶的應用定義和云的基礎設施能力是完全分開的。所以一個應用，不會再被局限于只能運行某種具體的平臺或者云服務上：對于這些應用運行時的選擇，只是應用描述中的一個可配置參數而已。而應用的運維特征，在實現層實際上就是每一個云基礎設施能力的模塊化實現。所以一旦一個應用描述與某個應用特征綁定，云平臺就可以自動將對應的云服務接入到應用運行時當中，從而避免了用戶陷入到“永無止境”的云服務開通和配置工作中。
不過，OAM 對于云端應用管理的價值，還遠遠不止更好的用戶體驗這么簡單。
應用特征系統：平衡可移植性和差異性
在 Open Application Model 的模型中，應用管理人員可以靈活搭配應用描述與應用特征，從而對接不同的云基礎設施能力到應用中。這種基礎設施能力通過 OAM 對用戶透出之后，實際上就能夠差異化的表達不同運行環境能夠為應用提供的不同基礎設施能力。
舉個例子，一位開發者定義了一個叫做“車”的應用描述，并做出了如下敘述：
要有安全性要能有操控能力要有行使動力然后，他把這樣的應用描述交給了云平臺，云平臺根據這個描述，為它綁定了一組比較基礎的“應用特征”：
安全：安全帶、氣囊、普通剎車操控：手動 5 檔、普通方向盤動力：普通發動機
這樣，這個應用在它的最終用戶看來，實際上就是一個“家用汽車”。
但是，過了一陣子，開發者決定對這個“車”進行一次升級。這時候，他該怎么做呢？
實際上，他什么也不用做。他只要告訴應用運維，為之前的“車”應用描述，綁定一組更加“強大”的應用特征即可，比如：
安全：高強度車架、懸掛減震、全身防護、賽車式剎車操控：手動 8 檔、賽車方向盤動力：賽車引擎
所以，一旦上述“更強大”的應用特征，同“車”應用描述綁定，我們就可以將一個“家用車”立刻升級成一部強大的“賽車”。而在這個過程中，應用開發和應用運維唯一要做的事情，就是像“樂高積木”那樣，靈活搭配和組裝不同的應用特征而已。
而更重要的是，OAM 的設計初衷之一，是要提供標準化云端應用管理體驗，這就需要“抹平”不同運行環境之間的不同，以便讓應用“ 一次定義，多處運行”。但與此同時，OAM 提供的應用特征系統，則使得云平臺標準化的暴露出自己的能力之后，用戶依然可以通過對比不同運行環境的應用特征的差異，從而更準確的選擇自己的應用要部署到哪個運行環境當中，真正意義上實現“Define Once, Run Where I Choose” 的交付體驗。所以說，應用特征系統，正是 OAM 在設計中平衡可移植性和差異性的一個重要的創新之舉。
OAM 項目的現狀與未來
OAM 開源項目，主要包括了兩部分內容：
1、Open Application Model Specification （OAM Spec）：這個項目是 OAM 模型的官方規范與標準庫。在這個代碼庫中，詳細的闡述和定義了 OAM 模型中的所有核心理念和詳細到具體字段的 API 規范。與此同時，這些所有的 Spec 也都原生提供了進一步的擴展規范，使得這個模型本身具備了接入任意運行時、模塊化任意云基礎設施能力、標準化描述任意應用運維特征的、高靈活度的模型約束力。可以看到，這個庫堪稱 OAM 的使用者和實現者的官方“圣經”。
OAM Spec 項目 GitHub 地址：https://github.com/oam-dev/spec
2、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 將會始終致力為云應用管理的參與者帶來智能手機一般的使用體驗，在保證可移植性和可擴展性的前提下，以標準化的方式幫助“應用”高效和高質量地交付到世界上任何一個位置。我們期待全世界每一位開發者和每一個云計算生態的參與者，都能加入到這個全新的應用架構模型的發展過程中來，共同打造一個繁榮的云端應用生態背后的標準模型和基礎依賴。
