作者 | Adrian Mouat

譯者 | 平川

策劃 | 萬佳

本文最初發佈於 Container Solutions，經原作者授權由 InfoQ 中文站翻譯並分享。

WASM 將無所不在：編譯目標、部署目標、IoT、外掛生態系統。這是正在發生的事。（1 到 5 年）

Rust 的流行度將繼續增加，未來幾年有望在 RedMonk 排行榜上超過 Go。（2 到 4 年）

Kubernetes 將迎來重要對手。如果它使用 WASM，並支援 GitOps 風格的模型，會是加分做法。（2 到 5 年）

區塊鏈生態系統將會崩潰，誰知道什麼時候呢。也許會悄悄地發生，幾年後我們將談論“區塊鏈的冬天”。誰知道呢？（1 到 10 年）

供應鏈安全將是一個大問題。在未來兩年內，將會有更多像 SolarWinds 這樣規模的駭客組織（可能已經有了，只是我們不知道）。供應鏈工具（我不願意稱之為“解決方案”）將是一個很大的增長點，但要在行業內被廣泛接受（例如，讓每個人都使用 SBOM）仍然有很漫長的路要走。（大約 2 到 10 年）本條勉強算是一個預測，無伺服器將繼續增長，而且慢慢會成為主流正規化。（10 年？Kubernetes 還有很大的發展空間。）不過，在人們學會使用新正規化設計系統架構之前，它還會經歷更多的反彈和“失敗”。（未來 2 年）

我們將會看到，企業為了節省成本，會部分地遷回到本地資料中心。（2 到 5 年）

這可能是本文最具爭議 / 不可能的觀點。有那麼丁點可能會出現百億級的 AI 公司，利用智慧合約奴役全人類。（10 到 20 年）

好吧，雖然不希望，但 AI/ML 的發展還是有可能在多個行業中造成大規模的破壞。我不認為我們會發展出一種通用人工智慧，但在具體的領域會有大的飛躍。這可能會導致大量工作崗位消失，比如卡車司機。我們可能會很驚訝，竟然是那些行業受到影響。（2 到 10 年）（我不知道何時會發生，但變化可能突然到來。）

類似的，GPT3 類的助手（高效地自動完成所有事情）將廣泛應用。藝術家、作家、開發人員、操作人員、作曲家都會使用。（1 到 4 年）

程式語言

首先宣告，我不是一名程式語言專家。我認為有些領域自己需要多瞭解一下，這是其中一個，我很願意多做些研究。

最近幾年，似乎有一種向型別化語言轉變的趨勢，最明顯的是 TypeScript 和 Rust。現在大多數 JavaScript 框架都使用了 TypeScript。根據最近的 GitHub Octoverse 報告，TypeScript 是 10 大程式語言之一。我認為 Rust 的流行度也會有很大的提升，越來越多的底層軟體使用 Rust 編寫，還有些是為了安全性和效能而移植到 Rust。此外，它也非常適合 WebAssembly（WASM）生態系統，因為它可以編譯成一個很小的 WASM 二進位制檔案，這歸功於它沒有執行時或垃圾收集（GC）。在現代程式語言中，沒有垃圾收集可謂是異類，這源於 Rust 非同尋常的記憶體模型以及所有權和借用的概念。看下 RedMonk 排行榜，再考慮下推動 Rust 發展的因素，在未來幾年，Rust 的流行度很可能會超過 Go。

再長遠點看，我認為會有新的語言流行，它們基於 Rust 的概念構建（主要是記憶體模型 & 借出 - 檢查），並且提供比較高階的特性。我認為會有一種從屬型別的語言（如 Idris）將型別系統帶入下一個層級，從學術界（或業餘語言）進入行業併成為流行的語言。

在開發微服務，尤其是使用了 Kubernetes 時，所使用的語言最好是那種可以生成比較小的獨立二進位制檔案的。此外，可以編譯成 WASM 的語言也可能變得越來越重要，因為我們可以藉此訪問各種 PaaS 和邊緣平臺。這兩個因素可能會限制 Elixir、Gleam 這類語言的增長（它們基於 Erlang VM）。（注意：像 LUMEN 這樣的專案可能會證明我這裡的說法是完全錯誤的。）

Kubernetes 和部署平臺

未來 5 年，Kubernetes（又稱 k8s）將繼續增長。但是，如果它不能做些什麼來解決快速增加的複雜性，那麼我們就會看到有強有力的競爭對手開始出現。我們正在進入這樣的階段，執行和管理 Kubernetes 變得太過複雜，使用者轉向使用像 GKE 這樣的託管服務，或者是僱傭專業的公司如 Giant Swarm 和 Container Solutions 來管理 Kubernetes。即使是使用了託管服務的公司，也會尋求專業公司的支援。這不一定是壞事（這些服務讓組織可以專注於業務），但也確實意味著，那些不願意為這些服務付費的客戶將會被更簡單的解決方案所吸引。

值得注意的是，這種複雜性並不是隱藏不見的。它已經浮出水面，影響到了使用者。嘗試用 kubectl run 命令啟動並執行一個 Demo 很簡單。但執行生產應用，並弄明白如何安全地暴露出去就需要了解一大堆不同的特性了，不可避免地，這就需要編寫比微服務原始碼還要長的 YAML 檔案了。

為什麼會這麼複雜？這在很大程度上是逐步演化而來的。開始的時候，我們做的事情很簡單（使用 Kubernetes 時更簡單），然後其中加入了對用例 x 的支援。接下來，我們認識到，如果它能做 z 這件事會更好，於是就重寫了一些東西，但得保持向後相容性。這就導致了問題本身並不存在的複雜性（額外的複雜性）。這意味著會有新的競爭者出現並取代它，因為它們沒有歷史包袱，可以汲取前人的成果，避免前人的錯誤。

換個說法，所支援的用例數量的增加導致了“80/20”問題，80% 的使用者僅使用 20% 的特性，但每個使用者所使用的 20% 並不相同。要想去掉特性很困難。新的競爭者則不存在這個問題，他們可以圍繞一個比較小的核心功能集構建一個新產品，並且可能修復 / 避免其他問題（100 英鎊賭他們不用 YAML）。

和之前一樣，我們先看小規模的變化。小型公司和個人將避免使用 k8s，而選擇更簡單的解決方案，可能是某種開源的 PaaS，而且很可能使用 WASM。未來幾年，Nomad 的使用可能會開始增加。開始的時候人們會說，“可以，但不用大規模使用 x”，但是慢慢地，問題解決了，有一場行業鉅變將在我們眼前發生。

還有一種可能是，Kubernetes 成為底層基礎設施層，其他東西都以此為基礎進行構建。因此，小專案可以使用看上去很簡單的 PaaS（如像 Knative 這樣的 FaaS），但是，PaaS 是基於 k8s 的。由於 Kubernetes 對資源的要求很高，以及其複雜性的日益暴露，所以我有點相信，這種做法會被大量採用。將 k8s 的優點提取到一個新系統中可能更簡單、更有效——在這方面，已經有許多探索性的工作，如 k3s、KCP 和 badidea。順便提下，在大型組織中，像 Backstage 和 Crossplane 這樣的內部平臺和工具將變得非常常見，即使 Kubernetes 消失了，它們也不會。

（如果你對構建 Kubernetes 終結者感興趣，那麼 Prolog 和這個討論值得一看。）

不管發生什麼，Kubernetes 都會以某種形式長期陪伴我們。它仍然在快速演化，我們看到，有一些技術很可能影響未來幾年。自定義運算子和 GitOps 將變得很普遍。一些創新性的 Kublet 實現如 Krustlet（支援將 WebAssembly 模組作為 pod 執行）可能會開始受到追捧。

WASM

WebAssembly 已經出現幾年了，但現在，它已經準備好大顯身手了。要理解其中的原因，可能最簡單的方式就是回想（假如你已經有了一定的年級）下 Java 最初喊出的口號：“一次編寫，到處執行”。我們被告知，Java 在哪裡都可以執行，完全可移植。它取得了巨大的成功，但完全沒有達到聲稱的水平。為什麼呢？

它很慢（至少人們是這樣認為的），而且很耗記憶體。尤其是在邊緣，它完全沒有用武之地。

你需要學習 Java（現在有許多種 JVM 語言，但以前的選擇很有限）。

編寫 JVM 實現很難，而且各種實現之間的差別給“一次編寫，到處執行”埋下了禍根。

在瀏覽器中執行（Applet）需要安裝外掛。

WASM 解決了所有這些問題。它相對更簡單、高效，而且更小。許多語言都可以編譯成 WASM。主流的瀏覽器中都已經有了成熟的實現。其安全性也很有說服力——WASI 專案讓你可以控制 WASM 可以做什麼，可以讀取什麼輸入，可以向哪裡寫以及可以進行什麼核心呼叫。

我們已經看到，有多個專案在其外掛系統中使用了 WASM，包括 Envoy 和 Ethereum。其應用只會擴大，因為它是如此有用。你可以在一個很細的粒度上控制外掛可以訪問什麼，同時又允許使用者可以選擇任何他們喜歡的語言來編寫外掛。

在許多情況下，WASM 取代了容器，我希望看到更多與 Kubernetes 的整合，以 Krustlet 已經展現出的潛力為基礎構建。更有意思的是，使用 WASM 來支援新的 PaaS 和 FaaS 平臺，包括 Fastly compute@edge 和 Cloudflare workers。

我們也看到了它在邊緣的應用，這主要歸功於其可移植性和磁碟空間佔用小。

話雖如此，WASM 還面臨著許多挑戰。我在上文中提到，已經有許多語言可以編譯成 WASM。這是真的，但這種支援參差不齊。Rust 似乎是排名第一的語言，因為它提供了很好的支援，而且生成的檔案相對較小（得益於前面提到的沒有 GC 和執行時）。AssemblyScript（一個面向 WebAssembly 的 TypeScript 版本）也很受歡迎。

雖然包括 Go 在內的其他語言提供了不錯的支援，但往往因為垃圾收集器實現或執行時特性導致檔案很大。其他語言實現基本還在起步階段。

許多重要的基礎設施專案如 WASI（該專案定義了 WASM 如何與主機環境互動）也是如此。ByteCode Alliance 應該在生態系統快速構建方面發揮重要的作用。

供應鏈安全

作為一個行業，我們在這方面做得一直很糟糕（部分原因是安全行業的激勵機制遭到了破壞）。令人驚訝的是，這並沒有導致攻擊行為增加。我們會越來越多地看到，組織不經意間就運行了已“中毒”的軟體版本，因為攻擊者已經能夠在某個階段注入自己的軟體——可以是編譯期間，也可以是分發階段或升級過程中。在某些情況下，你可能會面臨支付加密贖金的窘境，但是，我們將會看到“智慧攻擊”越來越多，它們會以已經被攻破的組織為跳板攻擊其他組織（如 SolarWinds）。

要解決這個問題，首先得想一下如何證明生產環境中執行的元件的來源。當務之急是讓 SBOM 以及類似的元資料成為標準做法，並普遍應用像 in-toto 和 Notary v2 這樣的工具。下文介紹的 GitOps 也可以發揮一定的作用，它對 CI 許可權和部署許可權做了清晰的劃分，並且讓我們很容易弄清楚誰為什麼做了什麼修改。

未來，攻擊的潛在影響可能非常大，這已經引起了政府的注意。白宮已經發出了稽核美國政府軟體供應鏈的指令，英國也在就供應鏈網路安全徵集意見。希望這是協同改進標準實踐、構建攻擊防禦工具生態的起點。

樂觀的預測是，這些專案和方法（或類似的東西）會得到有效的應用。悲觀的預測是，它們沒有得到有效的應用，我們會越來越頻繁地看到越來越具破壞性的供應鏈攻擊。

區塊鏈與加密貨幣

兄弟們，對不起，雖然我認為區塊鏈有其用途所在，但這個領域的大多數公司還是會失敗。在這個生態系統中，沒有足夠多可行的案例證明資金投入的合理性。如果你在這個領域，那麼我希望你是賣鏟子的。

有一個領域或許會證明我是錯的，那就是智慧合約。也許，這只是因為它讓我想起了 Accelerando——我們可以讓 AI 基於智慧合約構建一個帝國嗎？（那麼智慧合約將用什麼來寫？你猜對了，WASM。）另一個可能的應用場景是上文提到的供應鏈安全——是否可以使用區塊鏈來識別軟體的來源？

對於更普遍的“加密貨幣”，我希望看到有一種真正的方式可以實現小額支付和低成本（接近零成本）國際匯款。我確信，這是加密貨幣的承諾之一，但至今還沒兌現。當前，像 Coinbase 這樣的公司，其收費明顯高於股票經紀公司對類似服務的收費。

我們必須終止 Proof-of-Work 演算法所造成的荒唐的資源浪費。短期來看，Proof-of-Stake 似乎是唯一可取的替代方案，我們必須轉向這種模式。我真心希望看到比特幣的終結，但其所佔用的資金量和所擁有的支持者數量意味著這在短期內不會發生。

對於 NFT，我還是持懷疑態度，但我很喜歡今年早些時候的這篇文章。

GitOps 與 x-as-code

GitOps 的理念非常非常簡潔，即將 Kubernetes 叢集所需的狀態儲存在 Git 中。如果叢集的實際狀態出現異常，就進行調整（隱藏了很多不同的可能性）。當需要更改狀態時，Git 儲存庫會更新，然後叢集會輪流“調整”。這樣做有一個很明顯的好處，就是我們僅僅克隆該儲存庫就可以建立一個完全相同的叢集，所有的變更都有完整的日誌，我們還建立了一種討論以及審批變更（拉取請求）的機制。然而，實現 GitOps 並不像聽上去那麼簡單，也存在許多與之競爭的技術，包括 Kubestack、Flux 和 Argo CD。

我們已經把 GitOps 應用到 Kubernetes 下的技術棧裡，例如使用 Terraform 建立叢集。隨著微服務、無伺服器、服務網格和佇列、資料庫等 SaaS 元件的興起，曾經的應用程式問題（如將功能連線在一起）已經被推入了叢集或基礎設施層。基於此，我們顯然可以推斷出，YAML 檔案已不足以構建和定義叢集。我們需要成熟的程式語言。Pulumi 很早就看到了這一點，並抓住了機會，但我認為，我們還會看到許多輪的迭代和潛在的解決方案。再一次，WASM 可以在這方面發揮一些作用，讓使用者可以引入自己的程式語言。關於這一點，未來幾年就會清晰，但我預計，許多手寫的 YAML 會被 CDK、Pulumi 及類似的產品（更容易讀取和推斷）所替代，YAML 和 CloudFormation 將成為編譯目標。

無伺服器與 FaaS

上面這一點導致了 FaaS 解決方案（如 Lambda）的應用。這一定會發生，但不像一些支持者所認為的那樣是一項明確而簡單的變化。要想有效地使用 FaaS 需要設計一種不同的應用程式架構風格。佇列和訊息傳遞基礎設施成為必不可少的元件，要想構建可靠的服務，就要先從根本上了解它們的互動性。對於以前可以透過資料結構和函式呼叫的事情，現在必須重新建模，並作為一個支援錯誤處理的分散式系統來考慮。這個領域的最佳實踐和設計模式可能需要過一段時間才能夠標準化並轉變為常識。

與此同時，我並不清楚，Lambda 是否能承擔起所有這些工作。Cloudflare 和 Fastly 的邊緣計算 FaaS 服務很有吸引力，它們提供了令人印象深刻的效能和可擴充套件性，並透過 WASM 提供了語言靈活性。缺點是，它們缺少來自雲提供商的基礎設施支援，而且這些雲提供商也在構建自己的 CDN，從而弱化了 FaaS 的優勢。所有這些服務都是專有的，使得許多公司都怕被鎖定。為此，像 Knative 和 OpenFaaS 這樣的替代方案會受到歡迎，加劇市場的碎片化。

廣義上講，無伺服器（既包括 FaaS，也包括像資料庫和佇列這樣的 SaaS）將成為主導模式，但要走的路可能比我們預想的更坎坷。未來幾年，我們將既會看到成功的故事（“我們透過遷移到無伺服器每月節省了 1 萬”），也會看到災難性的故事（“我們放棄了無伺服器，因為那每月要花掉我們 1 萬”）。

AI 與機器學習

這個難以預知的領域讓我有點害怕。我接觸過一些執行智慧合約的公司，但在我看來，他們其實是科幻迷而非實用主義者。看看 GPT3（原論文）可以做什麼，我們就可以更好地瞭解正在發生的一切了。我能否寫一篇博文，其質量可以和喬治奧威爾的論文相媲美？是否所有的作者都開始使用 AI 作為合著人和編輯？卡車駕駛是美國最大的就業來源之一——未來 10 年，將會有多少司機會被 AI 取代？有多少行業的多少崗位會被取代？（更多更好的預測，請閱讀 Sam Altman 的文章和採訪）或者，只是另一輪炒作？

短期內，最主要的變化可能是基於 GTP3 及其後繼演算法的 AI“助手”和“自動補全”將無處不在。如果你正在寫一篇博文，那麼它會幫你補全句子。如果你正在開發一個 Web 應用，那麼它會幫你補全方法。如果你正在寫一首歌，畫一幅畫，草擬一份工程計劃，它都隨時可以幫助你。如果你迴避這種幫助，就可能被別人甩在後面。

具體到雲計算的發展，這體現在了 AI Ops 的增長上，機器學習被用來分析從正在執行的應用程式中收集的日誌和遙測資料，從而發現問題和需要最佳化的地方。

我不認為我們很快就可以開發出一種通用人工智慧，這種大幅的變化只會出現在幾種特定的行業和用例中。但給這些行業帶來的變化仍然可能是一場徹底的革命。這些變化可能在突然之間發生，好處會被少數擁有這項技術的公司所包攬，進一步加劇社會的經濟分裂。

我的恐懼源於，我甚至都沒有想象出其中的一些可能性，而 AI 變革幾乎是一夜之間就發生了。科幻作者經常說“奇點”，廣義上講，這是說當 AI 發展超過了特定的點，變化會加速，人類將無法預測或跟上這種發展。在這方面，有一些觀點可能比較誇張，但我絕對相信，AI 將產生我們未能預見到的重大社會影響。

混合基礎設施的興起

當前，本地部署、裸機和混合部署市場似乎都很活躍，既有新玩家，也有老玩家。我對這個領域的關注不是很多，所以可能會跑題，但我還是要繼續說。

外表上看，可能會覺得一切都在不可避免地走向公有云，但我認為，我們已經開始回到本地部署和混合部署。一路走來，傳統硬體公司，如戴爾、HPE，可能已經犯下了很多錯誤，他們似乎全都轉向了 *aaS 模型，客戶只需要按使用付費。起初，這聽上去似乎與擁有本地硬體不相符，但據推測，這意味著供應商提供硬體時會存在能力冗餘，並且保證在需要時快速提供更多的硬體。關於這個模型，有一件有趣的事情是，可以平衡投入、資本支出和運營支出。想降低單例項月成本？籤一份 5 年期的合同或提前購買硬體。因為業務模式沒確定而想要一種更靈活的模型？籤一份一年期的合同，但單例項成本更高。

HPE 的 GreenLake、Dell 的 Apex 專案就是這一模型的例子。考慮下 IBM 最近的收購以及其已有的產品和解決方案，我們有理由推測，他們也在採取類似的市場舉措。在這個領域，Nutanix 也明確提供了一個軟體控制平面，支援雲資源或本地硬體。控制平面的重要性再怎麼強調也不過分，因為只有可以輕鬆整合混合資源並維護基礎設施時，該模型才有效。

在這個領域，新玩家 Oxide 大概也有一些創新計劃，在硬體和管理程式的各軟體層之間提供更好的整合。值得注意的是，這與 Equinix、Scaleway 等裸金屬和資料中心公司當前提供的以及正在構建的東西差別並不是特別大——也許差別就在於我們所說的“本地”是什麼意思。這是說硬體只執行在自己的資料中心裡，還是說硬體是我的，但可以執行在其他人的資料中心裡？我必須擁有硬體嗎，還是也可以租用？

在此背景下，雲提供商和晶片製造商之間的關係也在發生有趣的動態變化。雲提供商希望晶片可以互換，這樣晶片就會更便宜，每隔幾年就可以更換。晶片製造商希望儘可能多地把晶片賣給雲提供商，同時又保持對市場的掌控。為了保有擁有不同需求的多樣化客戶群，晶片製造商會支援 HPE 和戴爾的舉措，以及其他有利於推動本地和邊緣計算平臺多樣化的工作。相比之下，雲提供商已經開始構建自己的定製晶片，並推向本地部署市場。

此外，雲提供商和 CDN 提供商（如 Cloudflare、Fastly）之間也存在著激烈的競爭。這兩家公司都已經開始提供無伺服器計算服務，他們使自己的資料中心儘可能地靠近使用者（邊緣計算的一種形式）。因為離終端使用者很近，所以他們有很大的速度優勢，似乎也有成本優勢。他們也有一個很大的缺點，就是提供的功能不如 AWS 等雲提供商廣泛——一般來說就是提供資料儲存和計算服務，其他的就很少了。雖然我預計這些服務會迎來大幅增長，但云提供商也會積極地進入 CDN 領域發起反擊。

出於降低成本和避免鎖定的考慮，我們將看到一些公司開始遷回本地 / 混合部署。雲將繼續佔據主導地位，尤其是在創業領域，但成熟的公司將會探索節省運營支出的可能性。也許，更困難的問題是，誰將是這場運動的最大贏家——傳統的硬體提供商、裸金屬和資料中心提供商、邊緣計算提供商、雲提供商，還是管理平面軟體提供商？

量子計算

量子計算這個領域我瞭解的少之又少，說的可能是胡話。

鑑於量子計算需要真空和接近絕對零度的溫度，我們不大可能在短時間內獲得量子筆記本。事實上，其成本如此之高，只有大企業和政府才負擔得起量子計算機的成本。不過，這並沒有將公眾趕出量子計算領域——主流雲提供商都已經宣佈研究量子計算和服務，並對外出租。他們可能在 NP 完全問題方面取得重大突破，如分子模擬和物流最佳化問題。這也可能意味著，對於那些負擔得起量子計算機的人來說，TLS 就失靈了。目前來看，量子計算可以為某些型別的問題帶來重要的速度提升，但在短期內不會顛覆計算。真正的影響可能是加速科學領域（物理、化學、生物模擬）的研究，然後反過來在其他地方取得突破性進展。

量子傳送似乎更有可能帶來對於大眾而言更重要的突破——我們能不能在地球兩端（及更遠的地方）實現超光速通訊？再說一遍，我認為，量子計算要對平民百姓產生影響還有很長的路要走。

https：//blog。container-solutions。com/10-predictions-for-the-future-of-computing