【編者的話】本文作者利用自己云原生工程師的優勢，分享了他對2021年及之后的云原生發展趨勢的看法，包括云原生IDE、邊緣側Kubernetes、云原生 + Wasm、FinOps崛起、更多的Rust出現在云原生、GitOps + CD/PD顯著增加、服務目錄2.0：云本地開發人員儀表盤、交叉云、主流eBPF等等。

我希望每個人都度過了一個美好的假期，因為2021年1月的頭幾周非常瘋狂，從叛亂到新冠病毒。在云原生（Cloud Native）領域，CNCF最近發布了年度報告，包含我們去年完成的所有工作。我建議每個人有機會都看一看這份報告，考慮到病毒大流行的情況，我們度過了頗有收獲的一年。

云原生作為我工作的一部分，相比我共事過的公司和開發人員，我有獨特的優勢，所以我想分享一下我對2021年及以后的云原生發展趨勢的看法。

云原生IDE

作為一個在Eclipse Foundation中花了相當一部分時間在開發人員工具上的人，我對最新的技術進展感到非常興奮。未來的開發生命周期（代碼、構建、調試）將主要發生在云上，而不是你本地的Emacs或VSCode設置中。最終，你將為每個pull請求獲得一個完整的開發環境設置，預先配置并連接到它們自己的部署，以幫助你開發和調試需求。這個技術的一個具體例子是通過GitHub Codespaces和GitPod實現的。雖然GitHub的Codespaces還在測試階段，但是你可以用GitPod來體驗一下，比如Prometheus。在一分鐘左右的時間內，你就擁有了一個具有編輯器和預覽環境的完全實時開發環境。這個開發環境（工作區）是用代碼描述的，并且可以像其他代碼工件一樣與團隊中的其他開發人員共享。

最后，我希望在明年看到云原生IDE領域驚人的創新，特別是隨著GitHub Codespaces進入測試階段，并變得更廣泛可用，這樣開發者就可以體驗這個新概念并愛上它。

邊緣側Kubernetes

Kubernetes是通過大規模數據中心的使用而誕生的，但Kubernetes將會像Linux在新環境中所做的那樣不斷發展。Linux的情況是，最終用戶擴展了內核，以支持各種新的部署場景，包括移動部署、嵌入式部署等等。我堅信Kubernetes將經歷類似的演變，我們已經看到電信公司（和初創公司）通過將VNFs轉換為云原生網絡功能（CNFs），以及k3s、KubeEdge、k0s、LFEdge、Eclipse ioFog等開源項目，將Kubernetes作為邊緣平臺進行探索。推動超規模云支持電信公司和edge的力量，加上重用云本地軟件的能力，以及在已經龐大的生態系統上構建的能力，將在未來幾年鞏固Kubernetes在邊緣計算領域的主導平臺地位。

云原生 + Wasm

Web Assembly（Wasm）是一項剛剛起步的技術，但我預計它將成為本地云生態系統中日益增長的實用程序和工作負載，特別是隨著WASI的成熟以及Kubernetes更多地用作前面所述的邊緣協調器。一個用例是支持擴展機制，就像Envoy使用過濾器和LuaJIT所做的那樣。與直接處理Lua不同，你可以使用支持多種編程語言的更小的優化運行時。Envoy項目目前正處于采用Wasm的過程中，我希望在任何環境中都能遵循類似的模式，即腳本語言是一種流行的擴展機制，將來會被Wasm全盤取代。

在Kubernetes的前沿，有一些項目，比如來自微軟的Krustlet，正在探索如何在Kubernetes中支持基于wasi的運行時。這并不奇怪，因為Kubernetes已經通過CRDs和其他機制進行了擴展，以運行不同類型的工作負載，如VM （KubeVirt）等。

另外，如果你是Wasm的新手，我推薦這門來自Linux Foundation的新入門課程以及excellection文檔。

FinOps崛起（CFM）

冠狀病毒的爆發加速了云本地的轉變。在危機期間，至少有一半的公司正在加快其云計算計劃……近60%的受訪者表示，由于COVID-19大流行，云計算使用量將超過之前的計劃（2020年云計算狀況報告）。除此之外，云財務管理（或稱FinOps）是許多公司日益關注的問題，在我過去6個月與正在進行云原生旅程的公司的討論中，有一半都提到了這個問題。你也可以認為云提供商不鼓勵簡化云財務管理，因為這樣客戶將會花費更少，然而，在我看來，圍繞云財務管理，真正的痛苦是缺乏開源創新和標準化（每家公司做的云成本管理都不同）。在CNCF環境中，沒有多少開源項目試圖使FinOps變得更容易，有個KubeCost項目，但它還處于相當早期的階段。

另外，Linux基金會最近啟動了“FinOps基金會”來幫助這個領域的創新，他們在這個領域有一些很好的介紹性材料。我希望在未來幾年里在FinOps領域看到更多的開源項目和規范。

更多的Rust出現在云原生

Rust仍然是一門年輕的編程語言，特別是當你以Redmonk的編程語言排名為例時。然而，我的感覺是，在接下來的一年里，你會在更多的云原生項目中看到Rust，因為已經有一些利用Rust的CNCF項目出現在有趣的基礎設施項目中，比如microvm Firecracker。雖然CNCF目前絕大多數的項目是用Golang編寫的，但我希望隨著Rust社區的成熟，在幾年內基于Rust的項目能夠與基于Go的項目相媲美。

GitOps + CD/PD顯著增加

GitOps是云本地技術的操作模型，提供了一套統一部署、管理和監控應用程序的最佳實踐（最初由來自Weaveworks的Alexis Richardson創造）。GitOps最重要的方面是通過聲明的方式描述所需的在Git中版本化的系統狀態，這本質上允許正確應用一組復雜的系統更改，然后驗證（通過Git和其他工具啟用的漂亮的審計日志）。從實用的角度來看，GitOps改善了開發者的體驗，隨著Argo、GitLab、Flux等項目的發展，我預計GitOps工具今年將更多地沖擊企業。如果你看看來自GitLab的數據，你會發現，GitOps仍然是一個新興的實踐，大多數公司還沒有探索它，但隨著越來越多的公司開始大規模采用云本地軟件，在我看來，GitOps將會自然而然地跟進。如果你有興趣了解更多關于這個領域的信息，我建議你查看CNCF中新成立的GitOps工作組。

服務目錄2.0：云本地開發人員儀表盤

服務目錄的概念并不新鮮，對于我們這些在ITIL時代長大的老年人來說，可能還記得CMDB（恐怖）之類的東西。然而，隨著微服務和云原生開發的興起，記錄服務和索引各種實時服務元數據的能力對于推動開發人員自動化至關重要。這可以包括使用服務目錄來了解所有權，以處理事件管理、管理SLO等。

在未來，你將看到開發人員儀表盤的趨勢，它不僅是一個服務目錄，還提供了通過各種自動化特性在一個地方擴展儀表盤的能力。最典型的開源例子是來自Lyft的Backstage和Clutch，然而，任何擁有相當現代的本地云部署的公司都傾向于擁有一個平臺基礎架構團隊，試圖構建類似的東西。伴隨著一個大型插件生態系統，開源開發人員儀表盤將更成熟，你將看到各地的平臺工程團隊加速采用儀表盤。

交叉云變得更加現實

Kubernetes和云本地運動已經證明了云本地和多云方法在生產環境中是可能的，數據清楚地表明“93%的企業有一個戰略，使用多個供應商，如微軟Azure、亞馬遜Web服務和谷歌云”（2020年云報告狀態）。Kubernetes多年來隨著云市場的成熟，有望開啟可編程的跨云管理服務。這種方法的一個具體例子體現在Crossplane項目中，該項目提供了一個開源的跨云控制平面，利用Kubernetes API的可擴展性來支持跨云工作負載管理（參見《GitLab部署跨云控制平面來提供多云部署》）。

主流eBPF

eBPF允許你在Linux內核中運行程序，而無需更改內核代碼或加載模塊，你可以將其視為一種沙箱擴展機制。eBPF允許新一代軟件擴展Linux內核的行為，以支持改進的網絡、監控和安全等各種不同的東西。從歷史上看，eBPF的缺點是它需要一個現代的內核版本來利用它，在很長一段時間里，這對許多公司來說都不是一個現實的選擇。然而，情況正在發生變化，甚至RHEL的新版本最終也支持eBPF，因此你將看到更多的項目從中受益。如果你看一下Sysdig最新的容器報告，你會發現Falco的使用率最近有所上升，盡管該報告可能有點偏向Sysdig，但它反映在生產使用中。所以請繼續關注并期待未來更多基于eBPF的項目！
責編AJX