|
新聞中心
當前位置：網站首頁 > 新聞中心
2021年云原生趨勢預測
【編者的話】本文作者利用自己云原生工程師的優(yōu)勢，分享了他對2021年及之后的云原生發(fā)展趨勢的看法，包括云原生IDE、邊緣側Kubernetes、云原生 + Wasm、FinOps崛起、更多的Rust出現(xiàn)在云原生、GitOps + CD/PD顯著增加、服務目錄2.0:云本地開發(fā)人員儀表盤、交叉云、主流eBPF等等。
我希望每個人都度過了一個美好的假期，因為2021年1月的頭幾周非常瘋狂，從叛亂到新冠病毒。在云原生(Cloud Native)領域，CNCF最近發(fā)布了年度報告，包含我們去年完成的所有工作。我建議每個人有機會都看一看這份報告，考慮到病毒大流行的情況，我們度過了頗有收獲的一年。
云原生作為我工作的一部分，相比我共事過的公司和開發(fā)人員，我有獨特的優(yōu)勢，所以我想分享一下我對2021年及以后的云原生發(fā)展趨勢的看法
云原生IDE
作為一個在Eclipse Foundation中花了相當一部分時間在開發(fā)人員工具上的人，我對最新的技術進展感到非常興奮。未來的開發(fā)生命周期(代碼、構建、調試)將主要發(fā)生在云上，而不是你本地的Emacs或VSCode設置中。最終，你將為每個pull請求獲得一個完整的開發(fā)環(huán)境設置，預先配置并連接到它們自己的部署，以幫助你開發(fā)和調試需求。這個技術的一個具體例子是通過GitHub Codespaces和GitPod實現(xiàn)的。雖然GitHub的Codespaces還在測試階段，但是你可以用GitPod來體驗一下，比如Prometheus。在一分鐘左右的時間內，你就擁有了一個具有編輯器和預覽環(huán)境的完全實時開發(fā)環(huán)境。這個開發(fā)環(huán)境(工作區(qū))是用代碼描述的，并且可以像其他代碼工件一樣與團隊中的其他開發(fā)人員共享。
最后，我希望在明年看到云原生IDE領域驚人的創(chuàng)新，特別是隨著GitHub Codespaces進入測試階段，并變得更廣泛可用，這樣開發(fā)者就可以體驗這個新概念并愛上它。
邊緣側Kubernetes
Kubernetes是通過大規(guī)模數(shù)據(jù)中心的使用而誕生的，但Kubernetes將會像Linux在新環(huán)境中所做的那樣不斷發(fā)展。Linux的情況是，最終用戶擴展了內核，以支持各種新的部署場景，包括移動部署、嵌入式部署等等。我堅信Kubernetes將經歷類似的演變，我們已經看到電信公司(和初創(chuàng)公司)通過將VNFs轉換為云原生網絡功能(CNFs)，以及k3s、KubeEdge、k0s、LFEdge、Eclipse ioFog等開源項目，將Kubernetes作為邊緣平臺進行探索。推動超規(guī)模云支持電信公司和edge的力量，加上重用云本地軟件的能力，以及在已經龐大的生態(tài)系統(tǒng)上構建的能力，將在未來幾年鞏固Kubernetes在邊緣計算領域的主導平臺地位。
云原生 + Wasm
Web Assembly(Wasm)是一項剛剛起步的技術，但我預計它將成為本地云生態(tài)系統(tǒng)中日益增長的實用程序和工作負載，特別是隨著WASI的成熟以及Kubernetes更多地用作前面所述的邊緣協(xié)調器。一個用例是支持擴展機制，就像Envoy使用過濾器和LuaJIT所做的那樣。與直接處理Lua不同，你可以使用支持多種編程語言的更小的優(yōu)化運行時。Envoy項目目前正處于采用Wasm的過程中，我希望在任何環(huán)境中都能遵循類似的模式，即腳本語言是一種流行的擴展機制，將來會被Wasm全盤取代。
在Kubernetes的前沿，有一些項目，比如來自微軟的Krustlet，正在探索如何在Kubernetes中支持基于wasi的運行時。這并不奇怪，因為Kubernetes已經通過CRDs和其他機制進行了擴展，以運行不同類型的工作負載，如VM (KubeVirt)等。
另外，如果你是Wasm的新手，我推薦這門來自Linux Foundation的新入門課程以及excellection文檔。
FinOps崛起(CFM)
冠狀病毒的爆發(fā)加速了云本地的轉變。在危機期間，至少有一半的公司正在加快其云計算計劃……近60%的受訪者表示，由于COVID-19大流行，云計算使用量將超過之前的計劃(2020年云計算狀況報告)。除此之外，云財務管理(或稱FinOps)是許多公司日益關注的問題，在我過去6個月與正在進行云原生旅程的公司的討論中，有一半都提到了這個問題。你也可以認為云提供商不鼓勵簡化云財務管理，因為這樣客戶將會花費更少，然而，在我看來，圍繞云財務管理，真正的痛苦是缺乏開源創(chuàng)新和標準化(每家公司做的云成本管理都不同)。在CNCF環(huán)境中，沒有多少開源項目試圖使FinOps變得更容易，有個KubeCost項目，但它還處于相當早期的階段。
另外，Linux基金會最近啟動了“FinOps基金會”來幫助這個領域的創(chuàng)新，他們在這個領域有一些很好的介紹性材料。我希望在未來幾年里在FinOps領域看到更多的開源項目和規(guī)范。
更多的Rust出現(xiàn)在云原生
Rust仍然是一門年輕的編程語言，特別是當你以Redmonk的編程語言排名為例時。然而，我的感覺是，在接下來的一年里，你會在更多的云原生項目中看到Rust，因為已經有一些利用Rust的CNCF項目出現(xiàn)在有趣的基礎設施項目中，比如microvm Firecracker。雖然CNCF目前絕大多數(shù)的項目是用Golang編寫的，但我希望隨著Rust社區(qū)的成熟，在幾年內基于Rust的項目能夠與基于Go的項目相媲美。
GitOps + CD/PD顯著增加
GitOps是云本地技術的操作模型，提供了一套統(tǒng)一部署、管理和監(jiān)控應用程序的最佳實踐(最初由來自Weaveworks的Alexis Richardson創(chuàng)造)。GitOps最重要的方面是通過聲明的方式描述所需的在Git中版本化的系統(tǒng)狀態(tài)，這本質上允許正確應用一組復雜的系統(tǒng)更改，然后驗證(通過Git和其他工具啟用的漂亮的審計日志)。從實用的角度來看，GitOps改善了開發(fā)者的體驗，隨著Argo、GitLab、Flux等項目的發(fā)展，我預計GitOps工具今年將更多地沖擊企業(yè)。如果你看看來自GitLab的數(shù)據(jù)，你會發(fā)現(xiàn)，GitOps仍然是一個新興的實踐，大多數(shù)公司還沒有探索它，但隨著越來越多的公司開始大規(guī)模采用云本地軟件，在我看來，GitOps將會自然而然地跟進。如果你有興趣了解更多關于這個領域的信息，我建議你查看CNCF中新成立的GitOps工作組。
服務目錄2.0：云本地開發(fā)人員儀表盤
服務目錄的概念并不新鮮，對于我們這些在ITIL時代長大的老年人來說，可能還記得CMDB(恐怖)之類的東西。然而，隨著微服務和云原生開發(fā)的興起，記錄服務和索引各種實時服務元數(shù)據(jù)的能力對于推動開發(fā)人員自動化至關重要。這可以包括使用服務目錄來了解所有權，以處理事件管理、管理SLO等。
在未來，你將看到開發(fā)人員儀表盤的趨勢，它不僅是一個服務目錄，還提供了通過各種自動化特性在一個地方擴展儀表盤的能力。最典型的開源例子是來自Lyft的Backstage和Clutch，然而，任何擁有相當現(xiàn)代的本地云部署的公司都傾向于擁有一個平臺基礎架構團隊，試圖構建類似的東西。伴隨著一個大型插件生態(tài)系統(tǒng)，開源開發(fā)人員儀表盤將更成熟，你將看到各地的平臺工程團隊加速采用儀表盤。
交叉云變得更加現(xiàn)實
Kubernetes和云本地運動已經證明了云本地和多云方法在生產環(huán)境中是可能的，數(shù)據(jù)清楚地表明“93%的企業(yè)有一個戰(zhàn)略，使用多個供應商，如微軟Azure、亞馬遜Web服務和谷歌云”(2020年云報告狀態(tài))。Kubernetes多年來隨著云市場的成熟，有望開啟可編程的跨云管理服務。這種方法的一個具體例子體現(xiàn)在Crossplane項目中，該項目提供了一個開源的跨云控制平面，利用Kubernetes API的可擴展性來支持跨云工作負載管理(參見《GitLab部署跨云控制平面來提供多云部署》)。
主流eBPF
eBPF允許你在Linux內核中運行程序，而無需更改內核代碼或加載模塊，你可以將其視為一種沙箱擴展機制。eBPF允許新一代軟件擴展Linux內核的行為，以支持改進的網絡、監(jiān)控和安全等各種不同的東西。從歷史上看，eBPF的缺點是它需要一個現(xiàn)代的內核版本來利用它，在很長一段時間里，這對許多公司來說都不是一個現(xiàn)實的選擇。然而，情況正在發(fā)生變化，甚至RHEL的新版本最終也支持eBPF，因此你將看到更多的項目從中受益。如果你看一下Sysdig最新的容器報告，你會發(fā)現(xiàn)Falco的使用率最近有所上升，盡管該報告可能有點偏向Sysdig，但它反映在生產使用中。所以請繼續(xù)關注并期待未來更多基于eBPF的項目！
作者：池劍鋒? 翻譯來源：Dockone.io
上一篇 盤點：云計算可為制造業(yè)提供哪些好處？ 下一篇 2021年，十問云計算
|
