開發與維運

讀完《雲原生架構白皮書》,我們來談談開放應用模型(OAM)

前言

7月21日阿里雲發佈了《雲原生架構白皮書》,該書由阿里雲眾多技術專家共同編撰而成,從雲原生定義、技術、架構、產品、實踐和發展趨勢幾個方面詳細介紹了雲原生這一近些年來大火的技術概念。受阿里雲邀請,我有幸在該書發佈前試讀了該書,但是由於最近比較忙,現在才有空和大家分享我的試讀感受。

熟悉我的朋友肯定知道,去年開放應用模型(OAM)概念一經提出,我就十分關注這一技術模型,最近更是參與到了該模型的實現項目 Crossplane 中,同社區中的同學共同實現雲原生技術“以應用為中心”這一終極願景。但是苦於社區中的資料都是英文,同時自己的理解又比較片面,在向身邊同事和其他不瞭解該項技術的同學科普 OAM 時,往往很難準確表達我的觀點。

OAM 是什麼?OAM 能做什麼?我們為什麼需要 OAM?每每被同事進行靈魂拷問時,總是不能拿出完整、條理、有說服力的東西,只能根據自己的理解以及一些零零散散的技術文章來說明我的觀點,很是不爽。但是當我讀到《雲原生架構白皮書》第三章中的開放應用模型(OAM)章節時,我知道我的問題解決了。該章系統的介紹了 OAM 這項技術的背景、定義、概念、實現和未來,讀者只要對雲原生稍有理解,就能輕鬆從這章中找到前面那些問題的答案。

那麼 OAM 到底是什麼?

從《雲原生架構白皮書》的內容出發,結合我的理解,大致將 OAM 的特點分為以下三點:

以應用為中心

今年是 Kubernetes 項目誕生的第六年,在這六年中,以 Kubernetes 為首的雲原生技術快速的改變著我們的技術架構,一個又一個的應用被拆分成微服務,打包成容器,運行在 Kubernetes 上。然而隨著微服務越拆越多,管理微服務的難度也呈指數型增長,Kubernetes 中並沒有”應用“這一概念,提供給我們的只有 deployment、StatefulSet 這樣工作負載粒度的資源,而一個應用,可能由多個 Deployment、Service、以及各種相關配套資源組成(如:HPA 用於彈性伸縮、Ingress 用於外部訪問等)。Kubernetes 並沒有提供給我們一個統一的資源或者說是方法來管理這些相關資源,各個公司只能開發自己的 PASS 平臺或設立規範約束自己的應用。

OAM 的出現補充了“應用”這一概念,建立對應用和它所需的運維能力定義與描述的標準規範。換言之,OAM 既是標準“應用定義”同時也是幫助封裝、組織和管理 Kubernetes 中各種“運維能力”的工具。通過 OAM 中應用的可交付對象 - Application Configuration,我們可以輕鬆的掌握我們的應用到底有那些 Kubernetes 工作負載組成,這些工作負載都使用了哪些運維特性,這些內容都會以 Kubernetes API 對象的形式展示,查看起來和查看 Deployment 與 Service 資源一樣方便。

Application Configuration

關注點分離

在實踐中,如果基礎架構和應用是由不同團隊維護的,由於各個團隊的關注點不同、對 Kubernetes 瞭解的程度不同、使用習慣不同,很容易產生混亂。實際上,對於業務研發人員和運維人員而言,他們並不想配置這些如此底層的資源信息,而希望有更高維度的抽象。這就要求一個真正面向最終用戶側的應用定義,一個能夠為業務研發和應用運維人員提供各自所需的應用定義原語。

通過組件(Component)和運維特徵(Trait)將業務研發人員與運維人員關注的不同特徵進行分離,再將不同的運維特徵(Trait)與業務組件(Component)進行綁定,最終再由OAM 可交付物 – Application Configuration 將所有組件組裝為一個統一的應用。研發與運維對資源的控制進行細粒度的劃分,可以有效的解決實際情況中存在的類似”我比你更懂 Kubernetes,要聽我的“的現象,避免了研發與運維之間的甩鍋與扯皮的情況。

面向最終用戶的應用管理平臺

這部分白皮書中並未詳細提及,但這也是我們現階段的主要工作和努力方向,經過不到一年的時間,OAM 的概念、思想已經基本成熟,而基於 OAM 的實現也已經出現 - Crossplane 項目,該項目目前為 CNCF 的 Sandbox 項目。

Crossplane 的出現解決了平臺維護者,也就是負責維護 Kubernetes 的基礎設施工程師的難題。但是對於應用研發和運維人員,也就是 OAM 的最終用戶,操作起來並不是十分的友好。基礎設施工程師為他們提供了一堆 CRD,他們必須逐個去挑選、測試和甄別,尤其是一些運維特徵(Trait)可能存在功能衝突,不能同時與一個業務組件(Component)綁定,這都都要應用研發和運維人員自己去學習和測試,雖然可以通過文檔來規範,但顯然這樣做並不優雅,這時 OAM App Engine(暫定名 RdurX)就出現了。

OAM App Engine 所在位置

OAM App Engine 的目標用戶群體是應用開發者,是希望終端開發者用戶可以感受到 OAM 提倡的各類應用管理理念帶來的價值。相比於其他基於 K8s 的應用管理平臺(如 rio ),OAM App Engine 將至少具備如下三大核心價值。

  1. 插件系統:App Engine 可以通過 OAM 具備快速納管 operator 的能力,輕鬆擴展各種能力。
  2. 用戶體驗:貼近開發者,一切設計以最終開發者使用體驗至上,複雜的概念做抽象,用戶熟悉的概念不隱藏。
  3. 最佳實踐:App Engine 將成為 OAM 實現的最佳實踐。

OAM 架構

OAM App Engine 由 CLI 命令行工具、 Dashboard UI 管理頁面和一系列編排文件/DSL 組成,目前還處於功能設計與開發當中,預計在8月底會和用戶見面。OAM App Engine 的開發者均來自 OAM 中國社區,來自不同的公司和組織,是真正的從社區中來,服務社區用戶。

歡迎對 OAM 有興趣的朋友加入,社區每雙週都會進行視頻例會,歡迎大家發表自己的見解或提出相關疑問。

OAM 中國社區

結語

《雲原生架構白皮書》的編寫集合了阿里雲眾多技術專家,基於這些年阿里雲海量的技術實踐,對雲原生這一當下十分火爆概念進行了十分深入的剖析,在分享知識和實踐經驗的同時還對雲原生相關技術、架構設計和發展趨勢等內容進行分析和描述,為那些對於雲原生這一概念還十分陌生和迷茫的開發者/管理者提供了一份乾貨滿滿的參考資料。這裡借用白皮書序言裡的一句話:

雲計算的下一站,就是雲原生;

IT 架構的下一站,就是雲原生架構 ;

希望所有的開發者、架構師和技術決策者們,共同定義、共同迎接雲原生時代。

《雲原生架構白皮書》下載鏈接 : https://developer.aliyun.com/topic/download?id=721

<img src="https://tva3.sinaimg.cn/large/ad5fbf65gy1gfm3j2vo79g20b90b9x6r.gif" style="width: 150px;">

Leave a Reply

Your email address will not be published. Required fields are marked *