開啟應用微觀時代 | 容器時代的數字化轉型方法論

青雲QingCloud發表於2019-03-26

談到數字化轉型,大多數文章的表達方式大概都是“在時代從網際網路進入產業網際網路的背景下,所有行業都應該擁抱雲端計算、大資料和人工智慧……”好像只要開出這三味藥名就能藥到病除。

談到容器與微服務,人們習慣圍繞著 Docker、Kubernetes、Service Mesh、FaaS、DevOps、Serverless……這些技術和概念在微觀層面打轉,結果在落地過程中出現很大的組織裂痕,舉步維艱。

本文試圖從企業業務核心訴求出發,在數字化轉型核心邏輯下,幫助企業釐清企業應用開發與運維全面向雲原生和微服務架構轉型的根本原因,以及轉型過程中涉及的各種關鍵問題、相關概念之間的關係。


2013 年誕生的 Docker,讓塵封已久的容器技術再一次興起。圍繞編排排程框架的百舸爭流,更是將容器推上了風口浪尖。直到 Kubernetes 脫穎而出,成為業界公認的容器編排標準,容器似乎代表了未來的一切,業界對容器技術的追捧更是達到了頂點。


然而,如同 Gartner 經典的技術成熟曲線所描述的,陡然而起的頂峰也意味著即將迎來的一輪“幻滅低谷”。當技術和生態日益蓬勃與成熟,越來越多的從業人員開始從單純對技術和理念的追捧,轉向對容器落地實踐與真實價值的思考。無獨有偶,另一份 Gartner 調研預測到 2020 年將有 50% 的企業會將容器應用於生產環境中。


這側面反映出業界,特別是終端使用者群體,對通過容器技術達成真正業務價值的期許。對於完成了高光亮相的容器和Kubernetes, 接下來面臨的是走向成熟前的最後一次大考:突破“幻滅低谷”,走入真正的生產實踐,創造商業價值。


以“微觀塑形”的新業務新應用


任何技術走入生產實踐的終極目標都是塑造企業創新性競爭力,為業務目標服務。


網際網路的出現為企業經營帶來巨大改變:全新的業務形態,更為廣闊的營銷空間,愈發高效的運轉效率。面向未來,企業業務將呈現更為徹底的網際網路化與數字化:從面向營銷、面向人的消費網際網路,通過物聯智慧延伸到面向生產與供應鏈(物與流程)的產業網際網路,同時將更加依賴通過資料探勘而形成的資料智慧進行決策。


企業 IT 將面臨超大規模、無數觸點、極高併發、極快速迭代更新等新的挑戰,需要更高的彈性和敏捷性。


數字化轉型 1.0 階段,企業更加關注基礎設施的敏捷性改造,通過系統基礎架構(計算、儲存、網路)全面雲化實現獲取敏捷和彈性的第一波升級。而在雲端計算基礎上,完成對更為貼近實際業務的上層應用的架構轉型,將更直接的大幅提升業務敏捷性,雲原生理念應運而生。


雲原生的最基本屬性是分散式的,但以何種粒度和維度實現模組化的切分,業界一直在不斷探索。Gartner 提出了一種應用(服務)粒度理論,將應用分成:Macroservice、Miniservice、和 Microservice,從粗到細依次對應不同的應用切分粒度。越細的粒度,將帶來越大的自由度和敏捷性。


微服務架構就是基於這一理念,將應用進行更細粒度的模組化拆分,並通過服務網格/服務治理技術建立起微服務間的通訊網路,從而構建起由獨立微小服務組織而成的應用(服務)網路叢集。


由於每個個體相對而言是輕量化的,可以單獨開發與部署,使得整個微服務應用具備了高度的動態化能力,可以不斷的快速迭代演化,也因此具有更強的業務敏捷性和彈性。


Gartner 基於微服務理念進一步提出了 MASA (Mash App and Service Architecture)應用架構,並預測這種理念將成為未來應用架構的主流趨勢。 應用開發開始從“巨集觀造像”逐步走入“微觀塑形”。


如同愛因斯坦的相對論為我們開啟了量子世界之門,微服務理念開啟了應用的“微觀世界”。但理論的真正落地,仍然需要一整套龐大的系統工程,包括完整的微服務工具集,與之匹配全新的應用開發與管理流程 ,以及符合微服務特性的基礎設施平臺。


>>>>新流程


DevOps 不僅僅是技術或者實現技術的工具,更是應用開發的一種組織架構和工作流程。DevOps 通過流程的重構希望實現從開發、測試到最終應用部署釋出全流程的貫通與高度自動化,從而實現敏捷開發。而正是這種對高度的動態特性的關注,讓 DevOps 方法論與微服務理念找到了共識。


>>>>新平臺


“輕量化”和“標準化”是容器最顯著的特性,而這兩個特性也恰恰完美匹配微服務應用開發的需求。輕量化匹配對“微觀”資源的需求,而標準化的封裝則為組網和標準化通訊提供了基礎。進入“微觀”世界最不可避免的是數量劇增帶來的管理複雜性,也因此容器的使用從來不從單體出發,而強調排程編排,這也正是 Kubernetes 有如壓艙石一般的價值所在。同時,業界也普遍認可容器是執行 DevOps 的最佳平臺。


總結下來,企業真正需要的是利用更敏捷靈活的應用交付能力持續鎖定創新競爭力,而通過落地微服務完成應用架構升級,則是取得這一目標的關鍵。


完善的容器平臺,提供基礎設施資源、完整的工具集、流程鏈及企業級工作平臺,為微服務及 DevOps 的全面落地提供一站式支援,應該成為所有企業容器建設的共同目標。


廣義架構的粘合劑

以上是從縱向的視角探討容器對單體應用的重構,而以橫向的視角,從巨集觀擴充的角度,亦可觀察到容器在多種新興應用場景中起到的粘合作用。


>>>>容器和雲 & 虛擬化


一方面,容器和虛擬化是互補關係,這一點越來越為大家所認可。在容器最火熱的時候,將容器視為虛擬化替代品的論調也不乏受眾。


但逐漸,大家在實踐中認知到容器與虛擬化各自的專長,也逐步區分開各自的應用場景。兩者都是基於分散式的架構理念,但是如之上提及的粒度理論,容器更敏捷更輕量,需要全方位的架構重組,適合短平快的新業務; 而虛擬化粒度更粗,靈活不及容器,但單體更強壯,更適合需要長期穩定執行的過載應用。因此在相當長的時間內,虛擬化和容器將以互補的關係在企業的生產環境中長期共存。


另一方面,容器是可以部署在虛擬化之上執行的。特別是在虛擬化大規模普及的背景下,這樣的部署方式更貼近使用者的使用習慣和真實環境,使用和運維都十分方便靈活,同時虛擬化在隔離性上的優勢也將補強容器的安全性。但代價是在一定程度的效能損耗,特別是網路效能。


與之相應的,是選擇將容器直接部署在物理機上,架構上減少一層,會大幅降低運維複雜度和效能損耗,同時資源利用率也將顯著提升,最終獲得更優的 TCO (總體擁有成本)。


兩者各具優勢,如何選擇則應訴諸於使用場景:更為靈活的虛擬機器方案比較適合開發測試環境,而 TCO 和效能更好的物理機方案則更適合長期執行的生產環境。在真實環境中,這兩者不是簡單的二選一,大多數時候是同時存在互相補充的,在一套完整的雲體系中統籌管理執行。


>>>>容器和 Serverless & FaaS


通過 Serverless 服務,使用者可以直接執行程式碼來處理負載,從而完全避免了應用執行環境或部署所帶來的各類消耗,提供極高的需求響應速度,面對突發性或事件驅動型的負載,Serverless 更具優勢。在目前這個階段,可以說容器為 Serverless 概念的落地奠定了技術基礎,不少服務商基於容器技術構建 Serverless 服務。


但未來很有可能,Serverless 只是作為從容器到 FaaS 的過渡階段的一個代名詞,或者以 Serverless 統稱類容器的輕量計算平臺。輕量化和高度敏捷快速是這類平臺的共同特徵,能滿足關於彈性伸縮、按需按量計費等敏態的需求。


>>>>容器和邊緣計算 & IoT


邊緣計算並不是把雲簡單複製到邊緣,而是一種體系化的計算框架設計。位居中心的雲端計算平臺和邊緣會有分工,處理不同場景下的負載。並且這種分工是動態和敏捷的,以適應整個架構的狀態和實際場景的需求。


比如在一個攝像頭智慧識別影象的 IoT 場景中,實現影象識別的人工智慧演算法應該執行在邊緣,以便更快速響應來自攝像頭的實時需求,但演算法不應該是固定不變的,應該在不斷的學習中迭代升級。完成學習的巨大算力可以由中央的雲負擔,而邊緣節點不斷快速迭代的需求則可以通過執行容器環境作為承載,同時還可兼顧邊緣節點對輕量化的要求。容器之於邊緣之於 IoT,是一種更好粘閤中心到邊緣的架構工具,同時也賦予整個物聯網更多的彈性與敏捷。


整體而言,容器作為一種輕量化的計算載體,為更多的場景賦予高度的彈性與敏捷性,也將更多場景有機的粘合在一起。從巨集觀的視角看,這也是一種廣義架構層面的彈性與敏捷,同樣在橫向上重構了場景連線的方式。


實踐中的系統性挑戰

真正走入生產實踐時,環境現狀是複雜多樣的,雜糅了多重視角,既需要關注單體應用的開發流程的設計,也需要在巨集觀全域性層面上考量不同平臺間的有序銜接,同時兼顧來自管理、組織、人才等層面的挑戰。


>>>>人才技能


作為最前沿的技術領域,業界對這種新事物充滿了好奇。大家最初接觸 Docker,都在感慨其便利性。但當 Kubernetes 出現後,很多人都在抱怨其複雜、難用。


一方面, Kubernetes 實際上定義了一套新的標準,裡面充斥著大量新概念和方法論,需要時間理解掌握。同時 Kubernetes 作為一個開源專案, 關注核心的發展,而將關於易用性和教育培訓的問題交給了廣大社群自行解決。


至今,原生 Kubernetes 大量的操作還需要通過命令列指令完成,這與企業 IT 從業者對 UI 化操作的預期還有相當的距離。而種類繁多且但參差不齊的周邊套件對初學者而言同樣無所適從。而且,Kuberentes 對部署後期的運維也提出了不少新課題,比如容器網路環境、持久化的資料儲存方案、運維監控等等。


另一方面, Kubernetes 技術橫跨企業的系統和研發,打破了固有工作邊界。典型企業場景中,應用開發和系統運維是兩個團隊,大家擁有不同的工作重心、知識結構和和習慣認知。


執行好一個叢集平臺需要有強壯的網路和儲存支援,而 Kubernetes 在這兩個方面還處於不斷髮展階段,成熟的方案和先例不多,應用開發人員覺得不可掌控;同時執行容器叢集是為了執行應用,不是作為一個 OS 來使用,系統人員又覺得沒有頭緒,兩方都需要理解對方的視角,也需要有全新的理念、方法論、組織架構、工作流程和新的工具,實現兩種角色的認知統一和協調推進。


毫無疑問,面對新技能的挑戰,企業都會想方設法幫助員工學習提升,但如何確保結果能夠得償所願呢?


現實的情況大多是,很多從業人員抱持著極大的熱忱而來,但面對陡峭的學習曲線又望而卻步,很快就喪失了堅持的動力,從而很快從好奇轉向了抗拒。也許,降低入門門檻,在沒有很專業的知識時就能先使用起來,在之後的使用中在不斷深入學習提升,創造一種學習實踐的正向迴圈,是更值得考慮的學習路徑。


>>>>企業 Legacy


容器帶來的創新是顛覆性的,而企業既有的應用架構、基礎設施、組織架構、業務流程、協同和管理方法等等,這些行之有年的穩定體系,不會輕易改變,也不可能輕易改變。


從技術層面,作為整體 IT 的一部分,容器平臺應該恰如其分的融入整體, 而絕不應該是一個獨立的技術體系。而一個全新平臺想要融入現有企業 IT 框架,需要提供良好的整合介面,在資源的排程和運維管理實現統一。同時,專業且舒適的使用者體驗也不可或缺,從使用操作角度最大程度的相容現有的流程和習慣。


組織和協作機制是另一種隱形的企業 Legacy,包括業務長期發展沉澱下來的工作流程和職能劃分,業務需求塑造下的組織形態,甚至企業文化奠定的協作機制,等等。但容器、DevOps 、微服務帶來的不止於技術,同樣也是方法論層面的重構,對這些既有流程和習慣帶來衝擊不可避免。


綜合來看,容器專案在立項初期,就需要合理安排推進路徑,合理選型,儘量減少對現有體系帶來大面積衝擊,逐步融入,長效演進,避免爆發式急進式的改造。


也可以參考雲端計算在企業內部落地的過程,很多企業先將雲平臺應用於部分創新業務場景,通過區域性業務熟悉掌握雲平臺的構建和運維能力之後再推進到全部生產環境。


>>>>工具的選擇


工具是落地的抓手,一方面要足夠豐富以滿足最直接的需求,而另一方面也需要足夠統一以發揮系統性的價值。


業務人員的需求往往是非常直接的:版本釋出頻率越來越密集該怎麼辦、如何做測試和生產的隔離、如何做灰度釋出、釋出到生產環境之前要有審批……等等,這都是企業每天要面對的具體的事。


容器技術是底層支撐平臺,和業務需求之間有一層鴻溝,Kubernetes 也不能完全彌補,更需要一個貫穿應用開發、測試、部署、執行管理全流程的解決方案級平臺產品,彌合開發和運維之間的認知、習慣與流程鴻溝。


這為圍繞 Kubernetes 而延展出的應用生態提供了巨大的空間:


向下,基於 CNI,CSI 等標準定義,大大小小的儲存、網路基礎架構廠商不斷把服務接駁進 Kubernetes 生態;


向上,面向各類業務應用場景不斷湧現出各類專案,有開源的也有商業,比如微服務治理的istio、映象倉庫 Harbor 等等,甚至一些遠早於 k8s 的老牌軟體也在調整自身去適應容器技術,比如 Jenkins 孵化的 Jenkins x 專案。


橫向,傳統 IT 領域的巨頭如 IBM、VMware,Rad Hat 等,紛紛宣佈支援 Kubernetes, 而大部分雲服務商則已經將雲端 Kubernetes 服務列為標配。


但生態快速生長的同時,碎片化的問題也湧現出來。各功能模組雖然選擇豐富,但缺乏整合。好的企業級的容器平臺不應該是把各種功能碎片化的拼接起來,提供一個大而雜的技術產品,而應該通過體系化的設計,將企業在業務“微觀塑形”過程中涉及的思維、方法、工具與能力有機地整合起來,提供貫通應用開發、測試、部署、執行管理全流程的平臺級解決方案,並儘量降低容器技術的使用門檻,簡化操作,最大程度相容企業既有的業務流程和管理習慣。


綜上,除了滿足功能和業務的設計目標,諸多延展而來的問題也需要統籌考慮,完整而系統化的容器平臺,應該包括:


流程重塑能力:

貫通工具到方法論的完整流程;


•抹平多角色技能與方法 gap 的能力:

讓多種角色各得其所,同心協力;


相容傳統的能力:

尊重既有資產,無縫融入現有 IT 管理流程;


• 強大的效能支援:

健壯的網路儲存支撐,確保高效穩定執行;


安全性

企業級安全體系,包括多租戶環境下的安全隔離機制。


只見樹木,不見森林,是目前很多企業進行容器建設時的真實寫照。對系統化思考的缺失,盲目追捧熱點,往往很快因為各種挑戰阻力導致整個專案的失敗。


企業真正需要的是對架構設計和實現方法進行系統性的頂層設計和統籌考慮,因地制宜地結合現狀和能力進行長期規劃和平臺選型。這是一個系統性工程,同時如果能在平臺工具方面獲得最大助益,則將大幅降低系統推進的難度,加速轉型程式。


展望


有人將容器作為基礎計算力使用,可以認為這是初級階段;有人從業務視角,把一個個業務通過容器交付和執行, 可以認為進入了進階階段;而更進一步,以容器平臺做依託,去打造諸如物聯網、大規模計算平臺,Serverless、FaaS 等,即構建平臺之上的平臺,以一種技術去創造新的技術……


這樣的容器進階之路,清晰的描繪出企業數字化轉型的歷程,從關注 IT 自身的效率提升起步,逐步將重心轉移至對應用和業務的賦能,最終匯聚單點能量打造平臺能力,並推動新一輪的技術轉型升級。


單一的容器個體是藐小的,但圍繞它展開的對動態架構的探索、對微觀方法論的思考、對技術價值的反思、和對未來應用的設計,則為我們開啟了具有無限可能的未來世界大門。


容器技術的本質,是面向應用和業務價值再思考與再塑造, 而方法則是通過“微觀”解構並重塑“巨集觀”。只有足夠深入而豐富的“微觀”,才能湧現真正巨集大而健壯的“巨集觀”。人類進入原子時代後掌握了核能,而容器之於我們呢?


換一種視角,重新思考容器。


開啟應用微觀時代 | 容器時代的數字化轉型方法論


“大道至簡 舉重若輕”,誠邀您參加將於 4 月 19 日在北京北辰洲際酒店舉辦的 KubeSphere 容器平臺產品釋出會,輕量級排程全棧雲功能,助力企業快速步入雲原生之旅,點選閱讀原文或掃碼即可報名,帶你在數字化轉型中一步領先!


開啟應用微觀時代 | 容器時代的數字化轉型方法論


相關文章