「報告解讀」雲原生的技術探索與落地實踐

報告背景

編寫機構：

InfoQ

釋出時間：

2020年

雲原生概述

主要雲原生技術

雲原生基於開源策略走向全新競合

雲原生技術的落地與應用

未來展望

前言

回首過去十年，雲計算的高速發展推動數字化轉型不斷深入，雲原生作為雲計算的下一站，在重構IT產業的同時，也為更多領域釋放了新的技術紅利與增長機遇。雖然雲原生概念由來已久，但對於雲原生的理念邊界、價值理解卻眾說紛紜。雲原生究竟如何界定？如何藉助雲原生視角透視雲計算、開源？雲原生又將如何賦能企業實現業務價值？InfoQ基於對雲原生技術生態的深刻觀察，將透過該報告為您展開一幅從技術演進、到商業策略革新、再到業務價值釋放的“雲原生”全景圖，梳理技術發展脈絡、剖析商業創新模式、觀察行業實踐的紅利釋放，看“雲原生”浪潮如何吞噬舊秩序、重塑新世界。

主要觀察發現：

1。雲原生本質上是一套指導軟體架構設計的思想，定義了一條能夠讓應用最大程度利用雲能力、發揮雲價值的最佳路徑，是基於雲計算PaaS概念全新容器化思路、更貼近企業業務側的價值延伸。

2。雲原生價值鏈貼近業務側的向上延伸，基於越來越多的非業務邏輯從應用程式剝離下沉到基礎設施，在此程序中，Kubernetes成為整個雲原生技術生態的底層技術標準與關鍵價值節點。

3。 ServiceMesh的核心價值在於實現業務邏輯與非業務邏輯的分離，Serverless將其功能從服務間同步通訊推廣到計算、儲存、資料庫等諸多場景，越來越多使用kubernetes服務的應用將轉化成為Serverless應用。

4。微服務帶來基礎架構複雜性激增，促使開發側和運維側關注點分離，不斷泛化的Serverless將成為DevOps的一種思想導向和組成部分，“輕運維”、“NoOps”、“自助式運維能力”將成為應用運維的主流方式。

4。開源策略成為構建雲原生技術生態圈的有效路徑，推進雲原生企業走向全新競合，開源社群成為其實踐平臺化戰略的最佳場所。

5。伴隨雲原生應用的不斷豐富，基礎設施的資源服務向精細化管理、更優成本、極致彈性、以及研發效能、交付最佳化的全生命週期轉化，將重構整個資訊產業，乃至醫療、製造、交通、教育等傳統行業的基礎設施構建形式，加速賦能全產業資訊化升級。

一、雲原生概述

雲原生：雲計算的下一站

十年網際網路浪潮下，熠熠生輝的是IT技術的飛速發展，從雲計算到雲原生，已經迎來送往了多個時代。雲計算帶來了從底層的算力分配到上層應用的快速更迭，而基礎軟體作為更好運用雲能力的有效路徑，更是不斷迸發出嶄新的思想洪流，雲原生在這樣的思潮下應運而生。

雲原生本質上是一套指導軟體架構設計的思想，建立在“未來的軟體一定生長於雲”的核心假設之上。依託該思想而設計的軟體：首先，軟體本身“生於雲、長於雲”；其次，這樣的軟體能夠天然整合“雲”環境，進而釋放“雲”的最大價值。

雲原生尚處高速發展變化之中，沒有確切的概念界定。可借鑑的說法是：雲原生定義了一條能夠讓應用最大程度利用雲能力、發揮雲價值的最佳路徑。具體來說，參考雲原生計算基金會（CNCF）的定義，雲原生包括容器化封裝、自動化管理、面向微服務、服務網格、宣告式API。符合雲原生架構的應用程式應該是：採用開源堆疊（Kubernetes+Docker）進行容器化，基於微服務架構提高靈活性和可維護性，藉助敏捷方法、DevOps支援持續迭代和運維自動化，利用雲平臺設施實現彈性伸縮、動態排程、最佳化資源利用率。

雲原生的前世今生

縱觀雲原生技術發展歷程，PaaS概念的普及為IT領域平臺型業務模式建立了思想先導，Docker的開源拉開了雲原生的序幕，也重新定義了PaaS的全新容器化思路。隨後，CNCF的誕生宣告雲原生技術演進的重心從容器轉移到以Kubernetes為核心的容器編排，社群開始在Kubernetes的基礎上構建上層的業務抽象，伴隨微服務、Serverless、FaaS等技術理念的實踐，Kubernetes逐漸成為雲原生技術生態的作業系統，企業在此基礎上搭建業務側的上層建築，最大程度利用雲價值。

1。平臺化和PaaS概念的普及

在2014年之前，企業上雲的普遍做法是租賃AWS或OpenStack虛擬機器、並透過指令碼或者手工方式部署應用，這一時期的開源PaaS專案因提供了應用託管能力而被廣泛接納。在Cloud Foundry等專案度過了艱難的概念普及和使用者教育之後，百度、華為、IBM等眾多廠商開啟了以開源PaaS為核心構建平臺層服務能力的變革，PaaS概念得以真正普及。

2。 Docker容器成為主流，PaaS被重新定義

Docker的出現重新定義了PaaS，Docker透過映象功能解決了應用打包的根本性問題，避免了使用者只能透過不斷試錯才能匹配不同執行環境差異的痛苦過程，伴隨著Docker原生的容器叢集管理專案Swarm的釋出，原有的PaaS時代宣告結束，並被重新定義成一套以Docker容器為技術核心，以Docker映象為打包標準的、全新的容器化思路。這也預示著一個以容器為中心的、全新的雲計算市場呼之欲出。

3。 Kubernetes成為雲時代的底層作業系統，上層應用不斷豐富

當Kubernetes透過先進的設計理念、可擴充套件的外掛機制以及開放的治理模式在整個社群推進民主化架構，基於Kubernetes API和可擴充套件介面先後湧現了Istio、Operator、Rook等優質專案。在成為分散式資源排程和自動化運維的事實標準的基礎上，Kubernetes逐漸體現出雲原生時代底層作業系統的特徵，向下封裝資源、向上支撐應用，特別是伴隨微服務、Serverless等技術理念的落地，Kubernetes支撐了更多的垂直解決方案，這些解決方案在使用者側形成了真正的商業價值。

雲原生的價值鏈生態

從技術發展的價值鏈演進來看，雲原生是雲計算應用價值的延伸，解決更貼近企業業務、架構、組織層面的關鍵問題。伴隨應用場景的不斷深化，Kubernetes已經成為整個雲原生技術生態的底層技術標準與關鍵價值節點，實現功能的不斷剝離下沉。而展望未來，中國規模化的應用場景將更好促進雲原生技術的創新演進，成為雲原生的最好生長土壤和試驗田。

1。雲原生是雲計算價值鏈的延伸與最大化

雲計算、雲原生如同很多基礎架構類產品一樣，其價值的產生並非源於自身，而是來自於使用者基於廣泛場景的大量應用。雲計算沿大資料價值釋放的生命週期不斷演化，透過不斷吸納先進技術賦能資料的獲取、儲存、處理分析和價值聯結等環節，為企業提供了高效、低成本的基礎設施資源。在雲計算逐漸由資源中心演變為創新技術熔爐的過程中，雲原生更進一步，幫助企業將應用和業務“雲化”，解耦業務和基礎設施，只關注業務邏輯和價值，將非業務邏輯的複雜性下沉到基礎設施，使基礎設施更高效、更高效能、更穩定可靠，從而更充分釋放雲的價值。

2。基於Kubernetes的“雲原生架構技術平臺”實現企業內各類業務的統一管理

伴隨雲原生的宏大版圖徐徐展開，Kubernetes成為了企業建設雲原生基礎架構和部署新一代應用服務的事實標準。根據容器創業公司Sysdig釋出的2019年容器使用報告，在容器編排平臺的選擇上，Kubernetes佔據了77%的份額。隨著亞馬遜、微軟、谷歌、VMware等IT大廠自2015年先後基於Kubernetes進行自身業務的雲原生改造，目前已有超過90個廠商提供了認證Kubernetes的雲服務或發行版，並提供了豐富的周邊軟體、服務的配套支援。一方面，越來越多的第三方開源專案以雲原生理念開發、部署和運維，最後演變成為一種雲服務；另一方面，企業也可以依託Kubernetes靈活的架構能力實現基礎設施資源的統一管理、業務架構的統一、以及構築統一的IT應用管理平臺，從而真正實現對企業內各類業務的統一管理。

3。中國規模化的技術沙盒成為雲原生創新的最好土壤

近年來，中國更具規模化的應用場景已經愈發成為雲原生技術創新、試驗的最好土壤。在這個擁有著14億人口、動輒電商大促、全產業鏈升級的試驗田裡，峰值交易量超50萬筆、資料總量近千PB的流量成為常態，中國健全的產業體系和龐大規模成為歷練雲原生技術的沙盒，用於建立和測試各種可能的解決方案。從中國走出去的開源專案如Apache Kylin、CNCF旗下的Harbor、TiDB/TiKV，還有在中國得到進一步歷練的Apache Pulsar，甚至包括Apache Flink乃至Kubernetes本身，都在中國場景的極限壓測下得到了進一步的升級。

根據中國信通院《中國雲原生使用者調查報告2020》顯示，我國雲原生技術使用者60%以上為網際網路企業，其中千人以上規模的企業佔比高達35。11%，中國應用的廣泛場景和龐大規模對雲原生技術的拉動已成事實。

二、主要雲原生技術

雲原生的技術體系看似紛亂繁雜，但在不同視角都體現著“牽一髮而動全身”的主線。從時間線來看，容器技術的發展催生了雲原生思潮，在底層解決了資源供給問題，隨後開源的Kubernetes成為容器編排的標準規範，當基於Kubernetes可擴充套件能力的開放應用平臺逐漸豐富，使其成為了雲原生生態最重要的基石。隨後Service Mesh、Serverless技術的核心思想更偏重在業務側實現價值——將更多的能力下沉到基礎設施，為應用的輕量化、上雲提供可能。

從技術需求的角度來看，微服務架構是解決單體複雜度問題的首選方式，卻帶來整個系統的整體複雜度大幅增加，容器技術和Kubernetes分別解決了微服務架構下大量應用的部署、以及容器的管理和排程問題，同時，Kubernetes也為Service Mesh提供了更好的底層支撐，也帶來了底層基礎設施的Serverless雲原生化和中介軟體能力的進一步下沉。

雲原生底層技術

容器

容器是將程序有效的劃分一個獨立空間，以便在獨立的空間之間平衡資源使用衝突的技術。本質上，容器是一種特殊的程序，其核心功能是透過約束和修改程序的動態表現創造出一個“邊界”，此外，其資源限制能力、以及基於映象功能表現出的“強一致性”，都使得容器技術成為雲原生最關鍵的底層技術之一。

Docker容器因具有和虛擬機器相似的隔離效果，而常常被稱為”輕量級“虛擬化技術，但這樣的說法並不嚴謹。在虛擬機器中，Hypervisor是最主要的部分，它透過硬體虛擬化功能，模擬出CPU、記憶體、I/O裝置等各類硬體，之後在這些虛擬的硬體上安裝了一個新的作業系統，即GuestOS，在虛擬的作業系統中執行的應用程序被相互隔離。

Docker與虛擬機器的差異體現在程序隔離方式的不同，Docker透過為應用附加額外設定的Namespace引數實現程序的隔離，並沒有一個真正的”Docker容器“執行在宿主機中，這樣的“障眼法”操作讓程序彷彿執行在一個與世隔絕的“容器”裡面，使得容器減少了額外的資源消耗和佔用，在敏捷和高效能方面具有很大優勢。

此外，容器的核心功能還包括基於Cgroups的資源限制能力、以及映象功能。Cgroups的作用是限制一個程序組能夠使用的資源上限，包括CPU、記憶體、磁碟、網路頻寬等資源。映象功能使得容器技術表現出“強一致性”，即在任何地點下載的映象內容完全一致，完全復現映象製作者當初的完整環境，這打通了“開發-測試-部署”等流程的各個環節，使得容器技術成為軟體的主流釋出方式。

編排與管理

Kubernetes

當容器映象成為應用分發的工業標準，能夠定義容器組織和管理規範的“容器編排”技術便成為了整個容器技術棧上的關鍵價值節點。主要的容器編排工具包括Docker公司的Compose+Swarm組合、Mesosphere公司的Mesos+Marathon組合、Google與Red Hat公司共同主導的Kubernetes專案、以及基於Kubernetes構建的Open Shift和Rancher專案。最終，Kubernetes專案憑藉優秀的開放性、可擴充套件性以及活躍開發者社群，在容器編排之戰中脫穎而出，成為分散式資源排程和自動化運維的事實標準。

Kubernetes專案的主要設計思想在於，從更宏觀的角度，以統一的方式來定義任務之間的各種關係，並且為將來支援更多種類的關係留有餘地。從功能的角度來看，Kubernetes更擅長按照使用者的意願和整個系統的規則，自動化地處理好容器之間的各種關係，即容器的編排，包括部署、排程和節點叢集間擴充套件等主要功能。而Mesos、Swarm等專案擅長把一個容器，按照某種規則，放置在最佳節點執行起來，即容器的排程。這也是Kubernetes專案最終脫穎而出的重要原因。

Kubernetes核心能力：

服務發現和負載均衡：

透過Service資源展現各種應用服務，結合DNS和多種負載均衡機制，

支援容器化應用之間的相互通訊。

儲存編排：

透過plungin的形式支援多種儲存，如本地、nfs、ceph、公有云塊儲存等。

資源排程：

設定pod排程的所需資源和資源限制，支援應用的自動釋出和應用回滾，管理應用的相關配置。

自動修復：

監測叢集中所有宿主機，自動發現和處理叢集內異常，更換需重啟的pod節點，使容器叢集執行在使用者的期望狀態。

金鑰和配置管理：

透過secret儲存敏感資訊，透過configmap儲存應用的配置檔案，避免將配置檔案固定在映象中，增加容器編排的靈活性。

橫向擴充套件功能：

實現基於CPU利用率或基於平臺級的彈性伸縮，如自動增加、刪除nodes節點。

Kubernetes專案由控制節點Master和計算節點Node組成。Master作為控制管理的節點，由三個緊密協作的獨立元件組成：kube-apiserver負責API服務，kube-scheduler負責資源排程，kube-controller-manager負責容器編排，另外，叢集的持久化資料由kube-apiserver處理後儲存在Etcd中，如Pod、Service等物件資訊。計算節點Node作為專案的工作負載，kubelet元件是其最核心的部分，負責Pod對應的容器的建立、啟停等任務，同時與Master節點密切協作，實現叢集管理的基本功能。

如今，Kubernetes專案不僅是容器技術的事實標準，更成為整個雲原生體系發展的基石，重新定義了基礎設施領域對應用編排與管理的各種可能。在整個雲原生生態中，Kubernetes專案起到了承上啟下的作用。對上，Kubernetes暴露出基礎設施能力的格式化資料抽象，如Service、Ingress、Pod、Deployment，都是Kubernetes本身原生API為使用者暴露出來的能力。而對下，Kubernetes提供了基礎設施能力接入的標準介面，如CNI、CSI、Device Plugin、CRD，讓雲能夠作為能力提供商，透過標準化的方式把能力接入到Kubernetes的體系中。伴隨著微服務、DevOps等技術理念的發展，基於Kubernetes可擴充套件能力的開放應用平臺將取代PaaS成為主流，而云的價值會迴歸應用本身，越來越多的開源專案會以雲原生理念去開發、部署和運維，最後直接演進成為一種雲服務。

微服務

微服務是服務架構演進的產物，在歷經單體架構、垂直架構、面向服務的架構（SOA）之後，微服務架構（MSA）可視為SOA架構的分散式實現方式。隨著業務發展與需求不斷增加，單體應用功能愈發複雜，應用迭代效率由於集中式研發、測試、釋出、溝通模式而顯著下滑。

微服務架構本質上是透過承受更高的運維複雜度來換取更好的敏捷性，其優勢在於小而治之、去中心化，但也導致基礎架構的需求、成本和複雜性激增。

目前為止，微服務並沒有統一的標準定義，結合Martin Fowler的描述：微服務架構是一種架構模式/架構風格，將單獨的應用程式開發為一套小服務並獨立執行在自己的程序中，相互之間使用HTTPAPI等輕量級機制通訊。這些服務圍繞著具體業務進行構建，透過完全自動化部署機制來獨立部署，並可使用不同的程式語言書寫，以及不同資料儲存技術，並保持最低限度的集中式管理。

Dubbo和Spring Cloud走向融合，更多的功能將被下沉到基礎設施。

Spring Cloud：

Spring Cloud是第一代微服務架構的翹楚，為實現微服務架構提供了一站式解決方案，作為一個全家桶式的技術棧，為開發者提供了快速構建分散式系統的通用模型的工具，包括配置管理、服務發現、熔斷器、智慧路由、微代理、控制匯流排、一次性令牌、全域性鎖、領導選舉、分散式會話、叢集狀態等。

Dubbo：

Dubbo作為由阿里巴巴開源的分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。核心部分包含：遠端通訊、叢集容錯、自動發現等。

近年來Dubbo生態不斷完善，2019年5月，Dubbo-go的正式加入Dubbo官方生態，隨後實現了REST協議以及gRPC的支援，打通了Spring Cloud和gRPC生態，Go專案與Java&Dubbo專案的互通問題得到了有效解決。時至今日，由於Spring Cloud Alibaba的出現，Dubbo將無縫整合Spring Cloud生態的各種周邊產品。

無論是Dubbo還是Spring Cloud，都或多或少限定於特定的應用場景和開發環境，缺少對通用性和多語言性的支援，並只解決了微服務Dev層面的問題，缺少DevOps的整體解決方案，這些都為Service Mesh的興起創造了條件。

作為微服務管理和通訊的完整解決方案，Dubbo和Spring Cloud將長期共存並走向融合，但其提供的部分功能將逐漸被基礎設施所取代。如部署在kubernetes叢集上的微服務，利用kubernetes的服務註冊和發現的功能會更加簡單；再如使用Istio架構，流量管理和circuitbreaker等功能將轉移到envoy代理，越來越多的功能會從應用程式剝離並下沉到基礎設施。

ServiceMesh

Service Mesh通常被譯為服務網格，在雲原生應用複雜的服務拓撲結構中，Service Mesh作為基礎設施層，負責在這些拓撲結構中實現請求的可靠傳遞。Service Mesh透過在請求呼叫的路徑中增加Sidecar，將原本由客戶端完成的複雜功能下沉到Sidecar中，實現對客戶端的簡化和服務間通訊控制權的轉移，當系統中存在大量服務時，服務間的呼叫關係表現為網狀，這也是服務網格名稱的由來。

我們可以從以下幾個特徵對Service Mesh的定義給出概括和總結：

抽象：Service Mesh將通訊功能從應用中剝離出來，形成一個單獨的通訊層，並將其下沉到基礎設施層。

功能：Service Mesh負責實現請求的可靠傳遞，從功能上來說和傳統的類庫方式並無不同。

部署：Service Mesh在部署上體現為輕量級網路代理，以Sidecar模式和應用程式一對一部署，兩者之間的通訊透過Localhost遠端呼叫。

透明：Service Mesh的功能實現完全獨立於應用程式，可以獨立部署升級、擴充套件功能、修復缺陷，應用程式無須關注Service Mesh的具體實現細節，即對應用程式是透明的。

Service Mesh的核心價值不只體現在其功能和特性，更在於實現業務邏輯和非業務邏輯的分離。非業務邏輯將被從客戶端SDK剝離，以Proxy獨立程序執行，從而將原來存在於SDK中的各種能力下沉到基於容器、Kubernetes或VM的基礎設施，實現雲上的託管、應用的輕量化，以幫助應用雲原生化。

主流的Service Mesh開源軟體包括Linkerd、Envoy和Istio。Linkerd和Envoy都直接體現了Service Mesh的核心理念，在功能上較為相似，即實現服務發現、請求路由、負載均衡等功能，解決服務之間的通訊問題，使得應用對服務通訊無感知。而Istio站在了更高的角度，將Service Mesh分為了Data Plane和Control Plane，由Data Plane負責微服務間的所有網路通訊，而Control Plane負責管理Data Plane Proxy，且Istio天然支援Kubernetes，這也彌合了應用排程框架與Service Mesh之間的空隙。

微服務落地需要一套完整的基礎設施，當容器成為微服務的最小工作單元，Kubernetes作為通用的容器管理平臺，能夠發揮微服務架構的最大優勢，使其成為雲計算的新一代作業系統。Kubernetes不僅能夠支援運行雲原生和傳統的容器化應用，並且覆蓋Dev和Ops階段，與Service Mesh的結合可以為使用者提供完整端到端的微服務體驗。

Serverless

Serverless將Service Mesh的應用場景泛化，不僅僅侷限於服務間的同步通訊，而是推廣到有網路訪問、透過客戶端SDK實現的更多場景，包括計算、儲存、資料庫、中介軟體等各種服務。如在螞蟻金服的Serverless實踐中，Mesh模式還延伸到了Database Mesh（資料庫訪問）、Message Mesh（訊息機制）、Cache Mesh（快取）等場景。

目前，Serverless通常被看作是FaaS（函式即服務）、BaaS（後端即服務）的集合，但Serverless只定義了一種使用者體驗，而不是某種技術，FaaS、BaaS都只是Serverless的一種實現方式。隨著Serverless技術的不斷成熟，越來越多使用kubernetes服務的應用將轉化成為Serverless應用。

雲原生中介軟體

傳統中介軟體類似於城市中的輸水管道，推動並管理資料從一個應用流向另一個應用，其業務耦合度高、不能為使用者帶來直接價值。進入雲時代，軟體的異構現象、互聯需求顯著增加，中介軟體被賦予了新的功能定義，即功能獨立、耦合度低、元件模組化，並被下沉到基礎設施，成為實現高效能、高可用、高伸縮性和最終一致性的分散式應用開發架構的關鍵組成部分。

從功能定義來看，中介軟體是一類連線軟體元件和應用的計算機軟體，它包括一組服務，以便於執行在一臺或多臺機器上的多個軟體透過網路進行

互動，屬於可複用軟體範疇。雲原生中介軟體包括

API、應用伺服器、TP、RPC、MOM，也可以承擔資料整合、應用整合的作用，任何位於核心和使用者應用之間的軟體都可以理解為中介軟體。

伴隨IoT、雲計算技術的快速發展，EDA（事件驅動架構）正在被越來越多的企業採納，透過事件的抽象、非同步化，來提供業務解耦、加快業務迭代，也正在從支援垂直行業轉向通用關鍵業務應用架構，應用在打包應用、開發工具、業務過程管理和監視等領域。

EDA往往透過訊息中介軟體實現，訊息中介軟體旨在利用高效可靠的訊息傳遞機制進行平臺無關的數

據交流，透過提供訊息傳遞和訊息排隊模型，實現在分散式環境下擴充套件程序間的通訊，並基於資料通訊進行分散式系統的整合。常見的訊息中介軟體包括ActiveMQ、RabbitMQ、RocketMQ、Kafka等，可應用在跨系統的資料傳遞、高併發的流量削峰、資料非同步處理等場景。

進入雲計算時代，雲廠商提供更加貼近業務的封裝，多采用自身的Serverless服務來執行事件負載，中介軟體的能力很容易透過雲服務來實現，包括阿里雲Function Compute、Azure Function、AWS Lambda都集成了事件處理。

未來，應用中介軟體將不再是能力的提供方，而是能力接入的標準介面，這個標準介面將透過HTTP、gRPC協議進行構建，並透過Sidecar解耦整個服務的接入層與應用業務邏輯，這與Service Mesh的思想一致。更進一步的，Sidecar模型能夠應用在所有的中介軟體場景，從而將中介軟體能力“下沉”到Kubernetes能力的一部分。

DevOps

伴隨雲原生開源生態不斷完善、以及複雜功能不斷下沉到雲，基本統一了軟體部署和運維的基本模式。在DevOps之前，從業人員使用瀑布模型

或敏捷開發模型進行軟體專案開發。DevOps作為Development和Operations的組合，被定義為實現軟體開發和IT團隊之間流程自動化的一組實踐，這些實踐建立在團隊之間協作文化的基礎上，填補了開發端和運維端之間的資訊鴻溝，以便更快、更可靠地構建、測試和釋出軟體，目前已經成為主流的軟體開發交付模式。

總體來看，DevOps包含了開發、測試和運維三部分。具體看來，它由多個階段組成：持續開發、持續整合、持續測試、持續反饋、持續監測、持續部署、持續運維，統稱為DevOps生命週期。

DevOps功能的分與合在資訊流轉層面得到了充分體現，在開發交付測試、測試回饋、交付釋出等階段，各類資訊的提供方、接收方使用優質的工具系統，進而實現順暢精準的傳輸資訊和高效的執行機械化操作。

從上述發展理念來看，DevOps的思想源於基礎設施層不夠強大、不夠標準化，所以業務側需要一套工具來黏合研發、運維人員和相應的基礎設施。但隨著Kubernetes和基礎設施越來越複雜，雲原生生態會做出相應的抽象和分層，每一層的角色只和屬於自己的資料抽象去互動，即開發側和運維側的關注點分離。不斷泛化的Serverless也將成為DevOps的一種思想導向和組成部分。在能力側，“輕運維”、“NoOps”、“自助式運維能力”會成為應用運維的主流方式。在應用側，應用描述會廣泛地進行使用者側的抽象，事件驅動和Serverless理念被拆分和泛化，可以被應用於FaaS之外的多樣化的場景中。