微軟與阿里雲合做推出「開放應用模型(OAM)」

英文原文：Announcing the Open Application Model (OAM)

原文標題：微軟與阿里雲合做推出「開放應用模型（OAM）」 用於 Kubernetes 及更多平臺的應用開發、運行的開放標準

Kubernetes 已經成爲業界領先的容器編排環境，這極大地推進了 Kubernetes 服務在全球各大主要公有云平臺上的顯著增加。可是，在 Kubernetes 的核心資源中諸如服務、部署等，從整個應用的角度來看，卻像是呈現出應用的離散狀態。此外，Helm chart 這樣的對象，雖然看起來像是能夠部署的應用，但真正部署以後，卻缺乏運行應用所需的應用中心模型。這就須要有一個定義清晰、完整一致的模型，來表達整個應用，而不只僅是它的模板或者是組件。正是出於這樣的考慮，微軟與阿里雲基於 Open Web 基金會展開合做，推出了開放應用模型（OAM）。

項目地址：https://openappmodel.io，OAM 項目目前由規範和實現兩部分組成

什麼是 Open Application Model？

OAM (Open Application Model) 是一個專一於描述應用的標準規範。有了這個規範，應用描述就能夠完全與基礎設施部署和管理應用的細節分開。這種關注點分離（Seperation of Conerns）的設計好處是很是明顯的。 舉個例子，在實際生產環境中，不管是 Ingress ， CNI，仍是 Service Mesh，這些表面看起來一致的運維概念，在不一樣的 Kubernetes 集羣中可謂千差萬別。 經過將應用定義與集羣的運維能力分離，咱們就可讓應用開發者更專一於應用自己的價值點，而不是」應用部署在哪「這樣的運維細節。 此外，關注點的分離讓平臺架構師能夠輕鬆地把平臺的運維能力封裝成可被複用的組件，從而讓應用開發者可以專一於將這些運維組件與代碼進行集成，從而快速、輕鬆地構建可信賴的應用。 Open Application Model 的目標是讓簡單的應用管理變得更加輕鬆，讓複雜的應用交付變得更加可控。

1、應用組件（Components）

在 OAM 中，「應用」是由多個概念共同組合而成的。 第一個概念是：應用組件（Components），它是整個應用的重要組成部分。 因此說，應用組件既能夠包括應用運行所依賴的服務：好比 MySQL 數據庫，也包括應用服務自己：好比擁有多個副本的 PHP 服務器。 開發者能夠把他們寫的代碼」打包「成一個應用組件，而後編寫配置文件來描述該組件與其餘服務之間的關係。 應用組件的概念，讓平臺架構師可以將應用分解成一個個可被複用的模塊，這種模塊化封裝應用組成部分的思想，表明了一種構建安全、高可擴展性應用的最佳實踐：它經過一個徹底分佈式的架構模型，實現了應用組件描述和實現的解耦。

2、應用部署配置文件（Application Configuration）

而爲了將這些應用組件描述變成一個真正運行起來的應用，應用運維人員會經過一個專門的、包含了全部應用組件信息的部署配置文件來實例化這個待運行的應用。 這個配置文件自己也是 OAM 規範中的一個聲明式 API，用來讓應用運維人員可以根據開發者或者平臺提交的應用描述，實例化出對應的、真正運行起來的應用。

3、應用運維特徵（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 項目的發佈只是邁出的一小步。咱們很是期待獲得您的反饋，並與你們密切協做，針對 Kubernetes 和任意雲環境打造一個簡單、可移植、可複用的應用模型。