Kubernetes 真正產(chǎn)生價(jià)值的地方也在于它的上層應用生態(tài)。

　　“未來(lái)的軟件一定是生長(cháng)于云上的”，這是云原生理念的最核心假設。而所謂“云原生”，實(shí)際上就是在定義一條能夠讓?xiě)�用最大程度利用云的能力、發(fā)揮云的價(jià)值的最佳路徑。因此，云原生其實(shí)是一套指導軟件架構設計的思想。按照這樣的思想而設計出來(lái)的軟件：首先，天然就“生在云上，長(cháng)在云上”；其次，能夠最大化地發(fā)揮云的能力，使得我們開(kāi)發(fā)的軟件和“云”能夠天然地集成在一起，發(fā)揮出“云”的最大價(jià)值。

　　云原生的概念大家并不陌生，很多企業(yè)也已經(jīng)基于云原生的架構和技術(shù)理念落地相關(guān)實(shí)踐。那么，這么多企業(yè)和開(kāi)發(fā)者熱衷和推崇的云原生，未來(lái)的發(fā)展趨勢如何？如何才能順應云原生的主流方向去發(fā)展？

　　我們邀請到阿里云資深技術(shù)專(zhuān)家、CNCF 技術(shù)監督委員會(huì )代表，etcd 作者李響和阿里云高級技術(shù)專(zhuān)家、CNCF 應用交付領(lǐng)域 co-chair 張磊分享云原生的理念、發(fā)展以及未來(lái)趨勢，為大家打開(kāi)新的思路和眼界。

　　以下內容共享給大家。

　　云原生里有一個(gè)非常關(guān)鍵的項目，就是 Kubernetes。Kubernetes 的發(fā)展非常迅速，它是整個(gè)云原生體系發(fā)展的基石。今天我們來(lái)觀(guān)察 Kubernetes 項目的發(fā)展特點(diǎn)，首先，Kubernetes 無(wú)處不在，無(wú)論是在云上，還是用戶(hù)自建的數據中心里，甚至一些我們想象不到的場(chǎng)景里，都有 Kubernetes 的存在。

　　第二，所有云原生的用戶(hù)使用 Kubernetes 的目的，都是為了交付和管理應用。當然這個(gè)應用是一個(gè)泛化的概念，可以是一個(gè)網(wǎng)站，也可以是淘寶這樣非常龐大的電商主站，或者是 AI 作業(yè)、計算任務(wù)、函數、甚至虛擬機等，這些都是用戶(hù)可以使用 Kubernetes 去交付和管理的應用類(lèi)型。

　　第三，今天我們來(lái)看 Kubernetes 所處的位置，實(shí)際上是承上啟下。Kubernetes 對上暴露基礎設施能力的格式化數據抽象，比如 Service、Ingress、Pod、Deployment，這些都是 Kubernetes 本身原生 API 給用戶(hù)暴露出來(lái)的能力。而對下，Kubernetes 提供的是基礎設施能力接入的標準接口，比如說(shuō) CNI、CSI、DevicePlugin、CRD，讓云能夠作為一個(gè)能力提供商，以一個(gè)標準化的方式把能力接入到 Kubernetes 的體系中。

　　這一點(diǎn)其實(shí)跟安卓非常類(lèi)似，安卓雖然裝在你的設備里，但是它能夠讓你的硬件、手機、電視、汽車(chē)等都能接入到一個(gè)平臺里。對上則暴露統一的一套應用管理接口，讓你能夠基于安卓系統來(lái)編寫(xiě)應用，去訪(fǎng)問(wèn)或者享受到這些基礎設施能力，這也是 Kubernetes 和安卓的相似之處。

　　最后， Kubernetes 本身并不直接產(chǎn)生商業(yè)價(jià)值，你不會(huì )花錢(qián)去購買(mǎi) Kubernetes。這就跟安卓一樣，你不會(huì )直接掏錢(qián)去買(mǎi)一個(gè)安卓系統。Kubernetes 真正產(chǎn)生價(jià)值的地方也在于它的上層應用生態(tài)。對安卓來(lái)說(shuō)，它今天已經(jīng)具備了一個(gè)龐大的移動(dòng)端或設備端應用的開(kāi)發(fā)生態(tài)，而對于 Kubernetes 來(lái)說(shuō)也是類(lèi)似的，只不過(guò)現在還在于比較早的階段。但我們已經(jīng)能夠看到，今天在 Kubernetes 上構建的商業(yè)層很多是垂直解決方案，是面向用戶(hù)、面向應用這一側真正能夠產(chǎn)生商業(yè)價(jià)值的東西，而不是 Kubernetes 本身這一層。這就是為什么我說(shuō) Kubernetes 發(fā)展跟安卓很像，當然這可能也是谷歌比較擅長(cháng)的一個(gè)“打法”：全力地去免費推廣一個(gè)“操作系統”，真正獲取商業(yè)價(jià)值的方式則是是去“收割”操作系統上層的生態(tài)價(jià)值而不是操作系統本身。

　　用戶(hù)使用 Kubernetes 的本質(zhì)目的是去交付和管理應用。從這個(gè)現象來(lái)看，如果 Kubernetes 發(fā)展下去，那么世界上所有的數據中心和基礎設施上面都會(huì )有一層 Kubernetes ，自然而然用戶(hù)就會(huì )開(kāi)始以 Kubernetes 為基礎去編寫(xiě)和交付以及管理其應用，就跟現在我們會(huì )以安卓這樣一個(gè)操作系統為基礎去編寫(xiě)移動(dòng)應用是類(lèi)似的。

　　這就會(huì )導致云上的大多數軟件和云產(chǎn)品都是第三方開(kāi)發(fā)的。第三方開(kāi)發(fā)是指所有人都可以面向一個(gè)標準界面去開(kāi)發(fā)和交付軟件，這個(gè)軟件本身既可以是自己的軟件，也可以是一個(gè)云產(chǎn)品。未來(lái)，越來(lái)越多的第三方開(kāi)源項目，如 MongoDB、Elasticsearch 等，都會(huì )以云原生理念去開(kāi)發(fā)、部署和運維，最后直接演進(jìn)成為一種云服務(wù)。

　　有了 Kubernetes 這樣一個(gè)標準，開(kāi)發(fā)者面對的就是一個(gè)類(lèi)似于操作系統的界面。由于有更多的應用是面向 Kubernetes 誕生的，或者說(shuō)面向 Kubernetes 去交付的，那么就需要有一個(gè)類(lèi)似于“豌豆莢”的產(chǎn)品，來(lái)作為云上的應用商店或者云上的應用分發(fā)系統，它的關(guān)鍵能力在于把應用無(wú)差別地交付給全世界任何一個(gè) Kubernetes 上面，就跟用豌豆莢把任何一個(gè)安卓應用交付在任何一個(gè)安卓設備上的原理是一樣的。

　　其實(shí)今天谷歌已經(jīng)在做這類(lèi)產(chǎn)品的嘗試了，比如 Anthos （面向混合云的應用交付平臺），雖然是一款混合云產(chǎn)品，但它本質(zhì)上是把谷歌云的服務(wù)，比如數據庫服務(wù)、大數據服務(wù)，去直接交付于任何一個(gè)基于 Kubernetes 的混合云環(huán)境里面去，其實(shí)就相當于一款云端的“豌豆莢”。

　　由于未來(lái)整個(gè)應用生態(tài)會(huì )面向 Kubernetes 去構建，那么基于 Kubernetes 可擴展能力的開(kāi)放應用平臺會(huì )逐漸取代傳統 PaaS 而成為主流。基于 Kubernetes 可擴展能力去構建一個(gè)開(kāi)放的應用平臺，其能力是可插拔的，能夠去交付和管理的應用類(lèi)型是多樣化的，這才更符合 Kubernetes 所構建的趨勢和生態(tài)，所以一些真正高可擴展的平臺層項目會(huì )大量產(chǎn)生。

　　另外，今天我們看到的 Kubernetes ，跟“理想”中的云原生應用生態(tài)之間其實(shí)還有很多路要走，這也是阿里云原生團隊一直在做的事情，基于 Kubernetes 在應用層構建更豐富的應用生態(tài)，幫助用戶(hù)實(shí)現多樣化的需求。

　　應用與能力的“ Operator 化”

　　縱觀(guān)云原生時(shí)代應用或者云的能力的發(fā)展方向，你會(huì )發(fā)現另一個(gè)趨勢，就是 Operator 化。Operator 是 Kubernetes 的一個(gè)概念，是指 Kubernetes 交付的一個(gè)實(shí)體，這個(gè)實(shí)體有一個(gè)基礎模型存在，這個(gè)模型分為兩部分：一部分是 Kubernetes 的  API  對象（CRD），另一部分是一個(gè)控制器（Controller），如下圖所示：

　

　　這里要區分兩個(gè)概念，自定義和自動(dòng)化。很多人會(huì )說(shuō) Operator 可以幫助我做自定義，因為很多人都會(huì )覺(jué)得 Kubernetes 內置的能力是不夠用的，所以用戶(hù)會(huì )利用它的可擴展能力去寫(xiě)一個(gè) Controller ，從而實(shí)現跟多自定義的需求。但自定義只是 Operator 中很小的一部分價(jià)值，我們今天對應用和能力做 Operator 化的核心動(dòng)力在于其實(shí)是為了實(shí)現自動(dòng)化，而且只有自動(dòng)化了，我們才能講云原生。

　　這是因為，云原生帶來(lái)的最大的紅利是可以讓我們最大限度、最高效地使用云的能力，二這種最高效、最大化的方式一定沒(méi)辦法通過(guò)人工來(lái)實(shí)現的。換句話(huà)說(shuō)，只有通過(guò)自動(dòng)化的方式去開(kāi)發(fā)、運維應用以及與云進(jìn)行交互，才能真正把云原生的價(jià)值發(fā)揮出來(lái)。

　　而如果要通過(guò)自動(dòng)化的方式跟云進(jìn)行交互，那么在云原生生態(tài)里，必須有一個(gè)類(lèi)似于Controller 或者 Operator 這樣的插件的存在。今天阿里巴巴在云上交付的 PolarDB、OceanBase 等，其實(shí)都有一個(gè)跟 Kubernetes 銜接的 Controller 的存在。通過(guò) Controller 與基礎設施、云進(jìn)行交互，把云的能力輸入到產(chǎn)品里面去。

　　在未來(lái)，會(huì )有大量的云上的應用和對應的運維能力、管理能力都會(huì )以 Kubernetes Operator 的方式交付。在這個(gè)背景下， Kubernetes 真正扮演的一個(gè)角色就是能力的接入層和標準界面。如下圖所示，這是一個(gè)非常典型的用戶(hù)側 Kubernetes 集群的樣子。

　　一個(gè)用戶(hù)的 Kubernetes 只有紅框里面這部分是 Kubernetes 原生提供的 API ，而大量的能力都是以插件化或者說(shuō) Operator 化的方式存在。就比如上圖右邊所有這些自定義的資源和能力全部來(lái)自于第三方開(kāi)發(fā)，通過(guò) Operator 這樣一個(gè)標準的形態(tài)開(kāi)發(fā)出來(lái)的能力來(lái)服務(wù)最終用戶(hù)的。這就意味著(zhù)在未來(lái)云原生的生態(tài)里面，基于 CRD Operator 的而非 Kubernetes 原生 API 的應用和能力會(huì )占到絕大多數。

　　隨著(zhù)這個(gè)趨勢的不斷演進(jìn)，越來(lái)越多的軟件和能力通過(guò) Kubernetes Operator 去描述和定義，云產(chǎn)品也會(huì )開(kāi)始默認以 Kubernetes 為底座，基于 Operator 進(jìn)行交付。

　　正是因為越來(lái)越多的 Operator 的出現，這里就會(huì )逐步需要一個(gè)中心化的方式去解決 Operator 潛在的穩定性、可發(fā)現性和性能問(wèn)題，也就是說(shuō)在未來(lái)很可能會(huì )有一個(gè)橫向的 Operator 管理平臺出現，對所有基于 Kubernetes Operator 開(kāi)發(fā)的應用和能力進(jìn)行統一管理，從而更好、更專(zhuān)業(yè)地服務(wù)用戶(hù)。

　　此外，由于未來(lái)每一個(gè)能力、每一個(gè)應用都需要去編寫(xiě) Operator ，所以說(shuō)對開(kāi)發(fā)者友好的 Operator 編寫(xiě)框架也是未來(lái)一個(gè)很重要的趨勢。這個(gè)編寫(xiě)框架可以支持不同語(yǔ)言，如 Go、Java、C、Rust 語(yǔ)言等，并且編寫(xiě)過(guò)程是專(zhuān)注于運維邏輯和應用的管理、能力的管理，而不是專(zhuān)注在 Kubernetes 的語(yǔ)義和細節上面。

　　最后，隨著(zhù)云原生生態(tài)的普及，云服務(wù)也將實(shí)現 Operator 化，并且面向多集群/混合云場(chǎng)景出現面向應用層的云服務(wù)標準化定義與抽象，并在云原生領(lǐng)域逐漸取代 IaC 項目（比如 Terraform 等）成為云服管理與消費的主流方式。

　　隨著(zhù)云原生以及整個(gè)生態(tài)的發(fā)展，我們看到應用中間件領(lǐng)域也隨之發(fā)生了很多改變。從原先最開(kāi)始的中心化 ESB ，到后來(lái)的胖客戶(hù)端，逐步演化到今天我們經(jīng)常提到的 Service Mesh 這樣一種 Sidecar 化的方式。

　　

　　其實(shí)今天你會(huì )發(fā)現，無(wú)論是云的能力還是基礎設施的能力，都在不斷豐富，很多原先只能通過(guò)中間件做的事情，現在可以很容易通過(guò)云服務(wù)來(lái)實(shí)現。應用中間件不再是能力的提供方，而是能力接入的標準界面，并且這個(gè)標準界面的構建不再基于胖客戶(hù)端，而是通過(guò)非常普通的 HTTP 協(xié)議、 gRPC 協(xié)議去做，然后通過(guò) Sidecar 方式把整個(gè)服務(wù)的接入層跟應用業(yè)務(wù)邏輯做一個(gè)解耦，這其實(shí)就是 Service Mesh 的思想。

　　目前 Service Mesh 只做了傳統中間件里面的流量治理、路由策略、訪(fǎng)問(wèn)控制這一層的事情。而實(shí)際上， Sidecar 這個(gè)模型可以應用到所有中間件的場(chǎng)景里，實(shí)現中間件邏輯跟應用業(yè)務(wù)邏輯完全解耦，讓?xiě)�用中間件能力“下沉”，變成 Kubernetes 能力的一部分。這樣應用本身會(huì )更加專(zhuān)一化，更多的關(guān)注業(yè)務(wù)邏輯本身。

　　伴隨著(zhù)這個(gè)趨勢，在 Kubernetes 這一層還會(huì )有另外一個(gè)趨勢出現，就是 Sidecar 的自動(dòng)化的、規模化的運維能力會(huì )成為一個(gè)必選項。因為 Sidecar 的數量會(huì )極其龐大，應用中間件很可能會(huì )演化成 Sidecar 集群，那么這些 Sidecar 的管理和規模化的運維能力，會(huì )是集群或者云產(chǎn)品的一個(gè)必備選項。

　　隨著(zhù)云原生生態(tài)的不斷發(fā)展，云原生理念的不斷普及， DevOps 的思想很可能也會(huì )發(fā)生一個(gè)本質(zhì)的變化，即下一代 DevOps 模型與體系。隨著(zhù) Kubernetes 的能力越來(lái)越多、越來(lái)越強大，基礎設施也會(huì )變得越來(lái)越復雜，那么基于這樣一個(gè)強大的基礎設施去構建一個(gè)應用平臺就會(huì )非常簡(jiǎn)單，并且這個(gè)應用平臺最終會(huì )取代傳統的PaaS平臺。

　　我們現在之所以在用 DevOps 這一套思想，實(shí)際上是由于基礎設施本身不夠強大，不夠標準化，不夠好用，所以我們需要在業(yè)務(wù)研發(fā)側做一套工具去黏合研發(fā)人員和基礎設施。例如，基礎設施提供的能力是一個(gè)虛擬機，怎么能讓虛擬機變成研發(fā)側想要的藍綠發(fā)布或者一個(gè)漸進(jìn)式的應用交付系統呢？這就需要一系列的 DevOps 的工具、 CI/CD 的流水線(xiàn)來(lái)完成。

　　

　　但是現在的情況已經(jīng)發(fā)生了變化。基于 Kubernetes 的基礎設施本身的能力已經(jīng)非常豐富，像藍綠發(fā)布這些能力本身就是 Kubernetes 可以提供的能力。在這樣的背景下， DevOps 的發(fā)展趨勢也會(huì )發(fā)生很大的改變：

　　在 Kubernetes 的背景下，“軟件”不再是一個(gè)由應用 Owner 掌控的單一交付物，而是多個(gè) Kubernetes 對象的集合，而這一堆 Kubernetes 里面的對象只有很少一部分其實(shí)才跟研發(fā)有關(guān)，所以說(shuō)有很多對象會(huì )不在應用 Owner 的認知范圍內，這就導致平臺必須去做關(guān)注點(diǎn)分離，研發(fā)側的關(guān)注點(diǎn)和運維側、系統側的關(guān)注點(diǎn)是完全不一樣的東西。也就是研發(fā)不用再考慮運維方面的細節，比如藍綠發(fā)布怎么做，水平擴容什么策略，只要把業(yè)務(wù)代碼寫(xiě)完交付就好。

　　伴隨著(zhù) Kubernetes 和基礎設施越來(lái)越復雜，概念越來(lái)越多，作為平臺層是不大可能讓研發(fā)了解所有的概念，因此未來(lái)云原生生態(tài)一定會(huì )做抽象和分層。每一層的角色只跟屬于自己的數據抽象去交互，研發(fā)側有一套自己的聲明式 API 對象，運維側有一套自己的聲明式 API 對象，每一層的關(guān)注點(diǎn)也是不一樣的，這會(huì )是未來(lái)整個(gè) DevOps 體系里發(fā)展的一個(gè)重要的背景。

　　云原生本身的關(guān)注點(diǎn)就是應用，在這樣一個(gè)背景下，Serverless 本身不再是一個(gè)獨立場(chǎng)景，不再局限在某幾個(gè)非常垂直的領(lǐng)域，而會(huì )變成云原生應用管理體系的一種泛化思想和天然組成部分。我從兩個(gè)層面解釋一下：一是在能力側，“輕運維”“ NoOps ”以及“自助式運維能力”會(huì )成為應用運維的主流方式。云原生生態(tài)上的應用管理會(huì )體現出一種輕運維的狀態(tài)，就是說(shuō)應用運維不再是一個(gè)人工的、非常復雜的過(guò)程，而是一組開(kāi)箱即用的、非常簡(jiǎn)單的模塊化操作。無(wú)論是通過(guò) Kubernetes 還是通過(guò)云原生能力，都是對下層基礎設施的一個(gè)模塊化的分裝，這跟 Serverless 所提倡的 NoOps 理念非常類(lèi)似。

　　二是在應用側，應用描述會(huì )廣泛地進(jìn)行用戶(hù)側的抽象，事件驅動(dòng)和 Serverless 理念被拆分和泛化，可以被應用于多樣化的場(chǎng)景中而不僅僅是今天狹義的 Serverless 場(chǎng)景比如 FaaS 或者 Container Instance，未來(lái)所有的應用都可以實(shí)現 scale-to-zero 。

　　第一，基于 Infrastructure as Data（IaD）的思想會(huì )成為一個(gè)主流技術(shù)，IaD 實(shí)際就是 Kubernetes 的聲明式 API ，聲明式 API 的核心在于把基礎設施、應用、能力以一個(gè)聲明式的文件、聲明式的對象去描述，那么這個(gè)文件或者對象本身就是“數據”。而 Kubernetes 或者基礎設施這一層是通過(guò)數據去驅動(dòng)的，這就是 Infrastructure as Data。這樣的思想會(huì )延伸出很多技術(shù)和前沿的思想，比如 GitOps 、管道型 YAML 操作工具（Kustomize/kpt）等。這樣的管道型應用管理會(huì )成為云原生生態(tài)里面一個(gè)非常主流的應用管理方式。

　　第二，聲明式應用定義模型（比如 OAM），以及聲明式的 CI/CD 系統和 Pipeline 會(huì )成為一個(gè)新的應用交付的模式。比如傳統的 Jenkins 是一個(gè)命令式的組織方式，而隨著(zhù)聲明式的 Pipeline 的出現，加上云原生生態(tài)、Kubernetes 的普及，基于 Infrastructure as Data 思想的流水線(xiàn)和下一代的 CI/CD 系統也會(huì )成為業(yè)界的主流。這跟以前的 CI/CD 和流水線(xiàn)有本質(zhì)的區別，因為這個(gè) CI/CD 系統里面所有的操作都是一個(gè)聲明式描述。正因為是聲明式描述，所有這些操作以及 CI/CD 里面的環(huán)節都可以托管到 Git 上，哪怕一個(gè)人工審核（Manual Approve）這樣的動(dòng)作都可以托管在 Git 里面，通過(guò) Git 去審計和做版本管理等。

　　Infrastructure as Data 的出現就是告訴我們，未來(lái)云原生的系統。一切皆對象，一切皆數據。隨著(zhù)對象和數據越來(lái)越多，對他們的管理、審計、驗證等就變得越來(lái)越復雜，那么圍繞它們的策略引擎（Policy Engine）會(huì )成為一個(gè)非常重要的需求。策略引擎會(huì )成為一個(gè)非常重要的組件，未來(lái) Kubernetes 所有的應用平臺可能都需要一個(gè)策略引擎的存在，幫助用戶(hù)處理不同場(chǎng)景下對數據的操作策略。

　　需要注意的一點(diǎn)是，雖然 Infrastructure as Data 會(huì )成為應用層的主流技術(shù)，但是它有一個(gè)“硬傷”，就是對最終用戶(hù)并不友好。因為人的大腦比較容易去處理流程化的、規則化的事情，而不是去處理一個(gè)靜態(tài)的數據，所以說(shuō)在 IaD 之上會(huì )有一層面向最終用戶(hù)的體驗層的存在。這就意味著(zhù) Kubernetes 不會(huì )把聲明式的數據直接交給最終用戶(hù)，而是通過(guò)其他方式來(lái)操作這些數據，比如通過(guò)一種能夠理解 Kubernetes 數據模型的動(dòng)態(tài)配置語(yǔ)言（DSL）來(lái)完成，或者通過(guò)基于 API 對象的 CLI 或者 dashboard 來(lái)完成，也可能是通過(guò)一種以應用為中心的交互與協(xié)作流程來(lái)完成。而最終用戶(hù)體驗層會(huì )決定產(chǎn)品有沒(méi)有黏性，這是云原生的這套體系有沒(méi)有黏性，是不是用戶(hù)友好的一個(gè)關(guān)鍵環(huán)節。

　　隨著(zhù)如前所述的下一代 DevOps 體系的發(fā)展，安全會(huì )從一開(kāi)始就變成應用交付的一部分。在業(yè)界大家稱(chēng)之為 DevSecOps ，就是從 day zero 開(kāi)始就把安全策略、對安全的考量、安全配置作為應用的一部分，而不是等到應用交付出去了甚至應用已經(jīng)上線(xiàn)了再去做事后的安全審計和管理。

　　隨著(zhù)云原生體系的發(fā)展，云的價(jià)值逐漸走向應用層，不斷向基于聲明式 API 、基于 IaD 的理念去發(fā)展，那么下層的基礎設施也會(huì )發(fā)生相應的變化。第一個(gè)變化是基礎設施能力聲明式 API 化、自助化。今天的云是基礎設施能力的集大成者，可以認為是一個(gè)無(wú)限的能力層，今天我們能想象到的基礎設施上所有的能力，云都可以提供，這跟以前的基礎設施完全不一樣。以前云的能力很薄弱，基礎設施的能力也很薄弱，所以才需要一個(gè)龐大的中間件體系和精密的 DevOps 體系來(lái)做一個(gè)“膠水層”，去彌補基礎設施跟應用、研發(fā)、運維人員之間的鴻溝。

　　而未來(lái)，應用才是整個(gè)云原生生態(tài)的主角。應用需要使用某個(gè)能力，那么云就會(huì )提供這個(gè)能力，并且是通過(guò)一個(gè)標準化的接入層來(lái)提供，而不是直接跟基礎設施打交道。云原生生態(tài)的發(fā)展會(huì )使得用戶(hù)側的視角發(fā)生很大的改變，從面向基礎設施變?yōu)槊嫦驊�用，從基礎設施有什么用戶(hù)才能用什么，變成用戶(hù)要什么，基礎設施就可以提供什么。以應用為中心的基礎設施會(huì )是未來(lái)基礎設施的一個(gè)基本形態(tài)。

　　這個(gè)理念跟 Serverless 理念非常類(lèi)似，我們可以將它稱(chēng)為底層基礎設施的 Serverless 原生化，這意味著(zhù)基礎設施會(huì )在未來(lái)也逐漸的聲明式 API 化，而聲明式 API 化帶來(lái)的一個(gè)直接結果就是他會(huì )變成一個(gè)自助化的基礎設施。

　　另外，由于基礎設施能夠實(shí)現聲明式 API 化，實(shí)現自助化，那么打造更加智能化的基礎設施就成為一個(gè)重要方向。因為基礎設施系統的模塊化能力變成了一個(gè)數據化的定義方式，那么就可以和容易的通過(guò)監控數據、歷史數據來(lái)驅動(dòng)基礎設施的運轉，也就是“自動(dòng)駕駛的基礎設施”。數據驅動(dòng)的智能化基礎設施會(huì )在未來(lái)成為可能，當然其前提是基礎設施本身實(shí)現聲明式 API 化和自助化。

　　與此同時(shí)，由于應用層本身會(huì ) Serverless 泛化，像 “scale to 0” 和 “pay as you go” 這些功能，會(huì )成為應用的一個(gè)基礎的假設，導致資源層也會(huì )走向極致彈性+無(wú)限資源池的方向。作為一個(gè)智能化的基礎設施，可以去做更加智能的調度與混部，從而提供極致的資源利用效能，實(shí)現成本的極低化。

　　與此同時(shí)，由于要實(shí)現極致的資源效能，就意味著(zhù)底層一定是一個(gè)強多租架構，并且這個(gè)強多租架構是面向 Kubernetes 的，跟 Kubernetes 有一個(gè)天然的、非常融合的集成。這體現在兩個(gè)方面：第一，在運行時(shí)這一層，這個(gè)基礎設施會(huì )傾向走基于硬件虛擬化的容器運行時(shí)而非傳統虛擬機的方向，比如 Kata Container ，并且認為神龍裸金屬服務(wù)器更適合做宿主機。伴隨著(zhù)這套技術(shù)的發(fā)展，輕量化的 VMM（虛擬化管理技術(shù)）會(huì )成為優(yōu)化容器運行時(shí)、優(yōu)化整個(gè)基礎設施敏捷度的一個(gè)關(guān)鍵技術(shù)和關(guān)鍵鏈路。

　　第二，強多租的控制面會(huì )針對不同租戶(hù)做物理隔離，而不只是邏輯隔離，這是 Kubernetes 數據模型的要求，即租戶(hù)的控制面板之間需要有強的物理隔離，這就是為什么我們講未來(lái)的強多租架構一定會(huì )面向 Kubernetes 來(lái)構建。阿里內部也是看到了這樣的趨勢，在不斷做一些嘗試，去更好地響應未來(lái) Serverless 原生化的基礎設施的發(fā)展趨勢。