區塊鏈生態系統將崩潰、Rust 超越 Go、無伺服器成主導,這十大計算機預測將成真?

【編者按】在IT圈有句名言:「活到老,學到老」。短短 6 字便道出技術發展速度之快。移動網際網路、雲端運算、大資料、人工智慧等技術革新在過去十年推動著時代巨輪不斷向前邁步。接下來,我們不妨再放眼未來,又有哪些技術革新在等著我們呢?

作者 | Adrian Mouat

譯者 | 彎月 責編 | 晉兆雨

出品 | CSDN(ID:CSDNnews)

內容提要:

  • WASM 將無處不在:編譯目標、部署目標、物聯網、外掛生態系統。(1~5年)

  • Rust 將持續流行,並在未來幾年內在 RedMonk 指數上超過 Go。(2~4年)

  • Kubernetes 將遇到強勁的競爭對手。另外,Kubernetes 可能會使用 WASM 並提倡 GitOps 風格正規化。(2~5年)

  • 區塊鏈生態系統即將崩潰,但是沒有人知道確切的時間。可能多年後,我們會談論「區塊鏈的冬天」。(1~10年)

  • 供應鏈安全會出現重大變革。在接下來的兩年內,我們將會看到更多類似於 SolarWinds 的駭客攻擊(可能已經發生了,只是我們不知道)。供應鏈工具將成為一個大幅增長的領域,但該行業廣泛採用供應鏈工具(例如讓每個人都使用 SBOM)的速度仍然非常慢。(2~10年)

  • 無伺服器將繼續增長並逐漸成為主導正規化。然而,隨著人們逐步弄清楚如何根據新正規化構建系統,無伺服器領域也會經歷更多的反彈和「失敗」。(未來兩年)

  • 為了解決成本,很多公司會改回使用內部基礎設施。(2~5年)這可能是最具爭議/最不可能的觀點。

  • 某個人工智慧將通過智慧合約建立一個價值數十億的公司,該公司會奴役整個人類(10~20年)。

  • AI/ML 的進步有可能對多個行業造成大規模破壞。我不相信我們能夠建立通用的人工智慧,但會在特定領域取得巨大飛躍。有些工作崗位會被 AI 佔據,比如卡車司機。至於哪些行業會受到影響,可能會出乎我們的預料(2~20年)。(雖然我不知道確切的時間,但這種變化會很突然。)

  • 以 GPT3 為基礎的 AI 助手將被廣泛使用。藝術家、作家、開發人員、運營商、作曲家都將「僱傭」 AI 助手。(1~4年)

程式語言

近年來,程式語言的發展似乎有一種向類型化語言轉變的趨勢,最引人注目的是 TypeScript 和 Rust。根據 GitHub Octoverse 最近的報告,如今大多數 JavaScript 框架都採用了 TypeScript,而且 TypeScript 也成為了排名前十的程式語言之一。

Rust 的增長有目共睹,越來越多的底層軟體都使用 Rust 編寫,還有很多軟體為了實現安全和速度移植到了 Rust。另外,Rust 也非常適合 WebAssembly (WASM) 生態系統,因為 Rust 可以編譯成非常小的 WASM 二進位制檔案,這主要是因為 Rust 沒有運行時或垃圾收集。對於現代語言來說,不包含垃圾收集是比較奇怪的現象,這是因為 Rust 不尋常的記憶體模型以及所有權和借用的概念。從 RedMonk 指數來看,考慮到推動 Rust 發展的因素,在未來幾年內 Rust 很可能會超越 Go。

從長遠來看,我認為一些基於 Rust 概念(主要是記憶體模型和借用檢查)的新語言將逐漸流行起來。同時還會將類型系統提升到一個新水平,我相信具有依賴類型的語言(例如 Idris)將從學術界躍升為行業內使用的流行語言。

在開發微服務時,尤其是 Kubernetes,使用可以生成小型獨立二進位制檔案的語言非常有優勢。編譯為 WASM 的語言也會變得更加重要,因為它們提供了各種 PaaS 以及邊緣平臺的訪問。這兩個因素可能會限制依賴 Erlang VM 的 Elixir 和 Gleam 等語言的增長。

Kubernetes 與部署平臺

在接下來的 5 年中,Kubernetes 將持續增長。但是,如果 Kubernetes 不採取措施解決日益增長的複雜性,那麼強大的競爭對手很快就會出現。如今這個階段,運行和維護 Kubernetes 的難度都非常高,所以很多使用者都採用了 GKE 等託管服務,或聘請 Giant Swarm 和 Container Solutions 等專業公司來管理 Kubernetes。即使是使用託管服務的公司也會尋求專業公司的支持。這不一定是壞事,因為在這些服務的幫助下,各個組織能夠專注於核心業務,但這也意味著不願為這些服務付費的使用者也很容易被其他替代方案所吸引。

請注意,Kubernetes 的複雜性不僅僅隱藏在幕後,甚至蔓延到了界面,並影響了使用者。如今通過 `kubectl run` 設置並運行演示還算比較簡單。但是運行生產應用,並弄清楚如何安全地公開應用,則需要了解大量的特性,不可避免地導致 YAML 檔案膨脹,甚至超過大多數微服務的源程式碼。

為什麼會有這樣的複雜性?很多都是發展的必然結果。剛開始的時候一切都很簡單(最初的 Kubernetes 也相對比較簡單),後來又添加了對某用例的支持。接著,我們意識到我們應該實現某個功能,另外還需重寫某些功能,但與此同時還必須保持向後兼容。結果就會導致軟體越來越複雜。這意味著新的競爭對手會出現並取代它,因為這些競爭對手沒有歷史包袱,可以從過去的成功和錯誤中吸取教訓。

換句話說,支持用例數量的增加會導致「80/20」問題:80% 的使用者只使用 20% 的功能,但每個使用者所使用的 20% 都不同。而刪除某些功能卻非常困難。新的競爭對手沒有這個問題,他們可以圍繞一套核心功能集構建新產品,並修復/避免其他問題。

與往常一樣,首先我們會看到一些小規模的變化。小公司和個人將避免使用 Kubernetes,轉而採用更簡單的解決方案,可能是某種開源 PaaS,也有可能使用 WASM。未來幾年內,Nomad 的採用會大量增加。雖然剛開始的時候,人們會說:「可以,但是你不能大規模使用某個軟體」,然而逐漸地這些問題都將得到解決,很快行業的另一場鉅變就會降臨。

另一種可能性是 Kubernetes 將成為一種底層基礎設施,其他一切功能都建立在其上。因此,小型項目可能會使用看似簡單、精簡的 PaaS(或類似 Knative 的 FaaS),但 PaaS 的底層卻是 Kubernetes。考慮到 Kubernetes 所需的資源量以及 Kubernetes 的複雜性,我有點懷疑這種方式是否會被大規模採用。更簡單、更有效的做法是將 Kubernetes 的精華提煉出來,並構建出新系統,我們看到了很多這方面的探索性工作,比如 k3s、KCP 和 badidea 等。附帶說明一下,像 Backstage 和 Crossplane 這樣的內部平臺和工具將在大型組織中變得越來越普遍,而且即使 Kubernetes 的問題得到解決,它們也不會消失。

將來無論發生什麼,近期內 Kubernetes 都會以某種形式存在。它仍在快速發展,而且我們可以看到在未來幾年內 Kubernetes 將產生很大的影響力。自定義操作器和 GitOps 將越來越普遍。一些創新 Kublet 的實現,比如Krustlet(支持將 WebAssembly 模組作為 Pod 運行)可能會受到關注。

WASM

WebAssembly 誕生已經很多年了,如今變得越來越普遍。論起 WASM 的普及原因,我們不禁回想起 Java 的口號:「一次編寫,到處運行」。當初我們得知 Java 可以在任何地方運行,而且可完整地移植,這是一個巨大的成功,但遠沒有達到 Java 所宣稱的水平:

● Java 非常慢且需要大量記憶體,因此無法在邊緣設備中運行。

● 你需要學習 Java(現在有很多 JVM 語言,但以前選擇有限)。

● 編寫 JVM 的實現並非易事,它們之間的差異導致了「一次編寫,到處調試」。

● 在瀏覽器中運行(小程序)需要安裝一個外掛。

而如今 WASM 解決了所有上述問題。WASM 相對簡單、高效且體積小。許多語言都可以編譯為 WASM。主流瀏覽器已經有了成熟的實現。安全方面則更加出彩,WASI 項目可以讓你精確地控制 WASM 可以做什麼、可以讀取什麼輸入、可以寫入什麼以及可以調用哪些核心。

我們看到很多項目都採用 WASM 作為其外掛系統,包括 Envoy 和 Ethereum。這種趨勢只會擴大,因為你可以細緻地控制允許外掛訪問的內容,同時允許使用者以他們喜歡的任何語言編寫外掛,這些都非常合理。

在許多用例中,WASM 都可以取代容器,我希望看到更多 WASM 與 Kubernetes 的集成,以 Krustlet 已實現的功能為基礎。更有趣的是,通過 WASM 支持新的 PaaS 和 FaaS 平臺,包括 Fastly compute 以及 Cloudflare workers。

我們還將看到 WASM 在邊緣設備中的使用,主要是因為其便攜性和檔案大小。

話雖如此,WASM 依然面臨著許多挑戰。比如支持多種語言編譯為 WASM。雖然很多語言都得到了支持,但支持的程度各不相同。目前排在第一位的是 Rust 語言,因為它具有良好的支持,而且可以創建相對較小的檔案(正如前面所說 Rust 不包含垃圾收集和運行時)。此外,AssemblyScript (面向 WebAssembly 的 TypeScript)也很受歡迎。

雖然 WASM 也支持其他語言(包括 Go),但檔案大小往往會因垃圾收集器的實現或運行時功能而膨脹。其他語言的實現還處於起步階段。

很多重要的基礎設施項目也是如此,比如 WASI,它定義了 WASM 與主機環境的互動方式。ByteCode Alliance 需要在快速構建生態系統方面發揮重要作用。

供應鏈安全

作為一個行業,我們在這方面的表現一直很糟糕(部分原因是安全行業的激勵措施不夠完善)。供應鏈沒有被大量駭客攻擊也算是幸運。將來我們會看到越來越多的組織意外運行「病毒」版本的軟體,因為攻擊者已經能夠在某些階段注入他們自己的軟體,可能是編譯階段、分發階段,甚至是更新期間。在某些情況下,還可能會被索要贖金,但我們將看到越來越多的高智商攻擊,即先入侵某個組織,將其當作踏板入侵另一個組織。

為了解決這個問題,我們必須認真思考如何證明生產環境中運行的元件的來源。我們應該將 SBOM 與類似的元資料作為標準做法,並大量採用in-toto 和 Notary v2 等工具。GitOps 方法也可以發揮作用,即清晰地分離 CI 與部署之間的許可權,並提供清晰地記錄:誰修改了什麼以及為什麼。

未來攻擊的潛在影響已經引起了各國政府的注意,美國白宮已發佈命令,要求審查美國政府的軟體供應鏈,而英國則呼籲就供應鏈網路安全發表意見。希望人們共同努力改進標準實踐,並建立有效防止攻擊的工具生態系統。

樂觀的預測是,上述項目和方法(或其他類似的方法)得到大量採用;悲觀的看法則是,越來越具有破壞性的供應鏈攻擊將越來越頻繁地發生。

GitOps 與XX即程式碼

GitOps 的概念非常簡潔,即將 Kubernetes 集群所需的狀態儲存在 Git 中。如果集群的實際狀態有偏差,則進行協調(這隱藏了很多不同的可能性)。當你需要更改狀態時,Git 儲存庫會被更新,並依次「協調」集群。這種做法的優勢非常明顯。我們能夠通過克隆儲存庫來創建相同的集群,我們擁有完整的集群修改日誌,而且還有完善的機制來討論和批准更改(拉取請求)。然而,GitOps 的實現卻沒有那麼容易,而且還有很多有競爭力的技術,包括 Kubestack、Flux 和 Argo CD。

我們已經將 GitOps 應用到了處於 Kubernetes 下層的技術棧,比如使用 Terraform 啟動集群。隨著微服務、無伺服器、服務網格以及 SaaS 元件(如隊列和資料庫)的興起,曾經有關應用程序的問題(比如將多個功能連接在一起),在某種程度上已經被推到了集群或基礎設施層。顯而易見,僅通過 YAML 檔案不足以構建和定義集群。相反,我們需要成熟的程式語言。Pulumi 很早就看到了這一點並開始著手,但我認為我們可能會看到更多的迭代和潛在的解決方案。同樣,WASM 可以讓使用者使用任意語言,因此也許能分一杯羹。在未來幾年內,這一點會越來越明確,但我認為大量手寫的 YAML 將被 CDK、Pulumi 等更易於閱讀和推理的工具代替,YAML 和 CloudFormation 將成為編譯目標。

無伺服器與 FaaS

由於上述幾點原因,Lambda 之類的 FaaS 解決方案將被大量採用。雖然這是必然的趨勢,但這種方式不夠整潔與簡單。為了有效地使用 FaaS,我們需要建立不同風格的應用程序架構。隊列和訊息傳遞基礎設施將成為必不可少的元件,在構建可靠的服務之前,我們必須從根本上理解它們的互動。以前可以通過資料結構和函數調用處理的功能,如今必須重新建模並考慮支持錯誤處理的分散式系統。該領域的最佳實踐和設計模式需要一些時間才能轉變成標準和常識。

同時,我不清楚 Lambda 是否會成為這些問題的解決方案。Cloudflare 和 Fastly 的邊緣運算 FaaS 產品非常優秀,通過 WASM 提供了出色的性能、擴展性以及語言靈活性。缺點是缺乏雲提供商支持的基礎設施,同時他們也在構建自己的 CDN(這其實抹殺了他們的優勢)。所有這些產品都是專有的,因此許多公司都擔心「被鎖定」。出於這個原因,Knative 和 OpenFaaS 等開放替代方案很受歡迎,並進一步分散了市場。

廣義的無伺服器(FaaS 與 SaaS 應用,比如資料庫和隊列等)將成為主導正規化,但發展前景依然比較坎坷。在未來幾年內,我們將看到一些成功的案例(「採用無伺服器之後,我們每月可以節省1萬美元」),也有一些災難性的案例(「無伺服器每月需要花費1萬美元,因此我們放棄了」)。

人工智慧與機器學習

我曾與從事智慧合約的 AI 公司有所接觸,對我來說,這個領域太不真實,更接近於科幻。為了更好地了解該領域,我們可以來看一看 GPT3 以及自動駕駛車輛的發展情況。AI 能寫小說了嗎?所有作者都可以將 AI 作為合著者或編輯了嗎?美國有大量的卡車司機,十年內有多少司機會被 AI 所取代?有多少行業的多少工作崗位會被 AI 所取代?還是說 AI 只是一種炒作?

短期來看,最主要的變化似乎是基於 GTP3 的 AI 「幫手」以及「自動補齊」,這方面的嘗試將層出不窮。如果你正在寫一篇文章,AI 可以幫助你自動補齊一個句子。如果你正在開發 Web 應用,AI 可以幫助你完成某個方法。如果你正在編寫一首歌,創作一幅繪畫,構思工程計劃,那麼 AI 也可以成為你的助手。而拒絕使用 AI 的人都會落後於時代。

我們在來看一看雲端運算的發展,這也反映出了 AI 運維的發展,所謂 AI 運維指的是通過機器學習分析應用程序的日誌和遙測資料,以識別問題並找出有待改進的領域。

我不相信我們能夠在短期內開發出通用的人工智慧,因此重大變化可能僅限於各個行業和具體用例。但這些部門的變化可能仍然是一場徹底的革命。這些變化很可能會突然發生,而只有少數掌握了該技術的公司會從中受益,從而進一步加劇社會的經濟分裂。

我擔心的是出現我們始料未及的可能性,因為 AI 的變化幾乎可以在一夜之間發生。科幻作家經常談論「奇點」,從廣義上說,「奇點」指的是當人工智慧跨越某個點時,變化就會加速,超出人類的預測或認知水平。有些觀點可能略顯誇張,但我絕對相信人工智慧將產生我們未曾預見的重大社會影響。

混合技術的崛起

目前,內部基礎設施、裸金屬和混合市場上有很多來自新老廠商的活動。首先聲明,我不是特別關注這個部門,因此我的一些觀點可能並不正確。

總的來看,公共雲是大勢所趨,但我相信我們正在向內部基礎設施和混合技術的採用邁進。戴爾和HPE等傳統硬體公司可能在此過程中犯了很多錯誤,但是似乎他們都在向著「XX即服務」的模式邁進,即消費者按使用量付費。起初,似乎這種方式與本地硬體背道而馳,但據說,供應商會提供容量過剩的硬體,並保證在需要時快速交付更多硬體。該模型的優點在於平衡承諾、資本支出和運營支出。你想降低每個實例每月的成本嗎?那麼請簽署 5 年的合約和/或預先購買硬體。在確定業務模型時想要更靈活的模型?你可以簽訂 1 年合同,只不過每個實例的費用更高。

HPE 的 GreenLake 和戴爾的 Project Apex 就採用了這類模型。鑑於 IBM 最近的收購以及現有的產品和解決方案,我認為他們將在市場上採取類似的措施。Nutanix 顯然也介入了這一領域,他們提供了雲資源和/或本地硬體的軟體控制平面。控制平面的重要性就無需過分強調了,只有在能夠輕鬆集成混合資源以及維護基礎設施的情況下,該模型才能發揮作用。新加入的 Oxide 大概也計劃在這方面進行一些創新,他們提供了更好的硬體與管理程序的各種軟體層之間的集成。另外,請注意,這完全不同於 Equinix 和 Scaleway 等裸金屬和資料中心公司目前提供以及正在建設的產品,不同之處在於對於「內部基礎設施」的理解,是在自己的資料中心運行的設施,還是在其他資料中心的硬體?我必須擁有這些硬體,還是可以租用?

在後臺,雲提供商和晶片製造商之間還有一些有趣的動態。雲提供商希望將晶片商品化,這樣每隔幾年他們就可以快速廉價地更換一次晶片。而晶片製造商則希望儘可能多地向雲提供商銷售晶片,同時保持對市場的控制。為了滿足各種客戶群的不同需求,晶片製造商可能會支持 HPE 和戴爾,以及任何能夠促進多樣化內部基礎設備和邊緣運算平臺的舉措。相比之下,雲提供商已經開始構建自己的定製晶片並進軍本地市場了。

此外,雲提供商還會與 Cloudflare 和 Fastly 等 CDN 提供商發生衝突。這兩家公司都已開始提供無伺服器計算服務,這些服務利用其資料中心儘可能地拉近與客戶的距離。所謂近水樓臺先得月,因此他們在速度和成本方面都佔據主要優勢。他們最大的缺點是無法訪問 AWS 等提供的大量功能,通常你只能獲得資料儲存和計算服務,僅此而已。雖然我認為這些服務會大幅增長,但云提供商為了反擊也在積極地向 CDN 領域擴展。

鑑於潛在的成本節約以及避免「被鎖定」,我們將看到有些公司將退回到內部基礎設施與混合方案。雲將繼續佔據主導地位,尤其是在創業領域,但成熟的公司會衡量他們能否節省大量的運營成本。那麼,究竟誰能成為這場運動的最大贏家呢?傳統硬體供應商、裸金屬與資料中心供應商、邊緣運算供應商、雲供應商還是管理平面軟體供應商?

量子計算

量子計算也是備受關注的一個領域,儘管我對該領域的了解也很有限。

鑑於量子計算需要真空和接近絕對零度的溫度,似乎短期內我們不太可能看到量子膝上型電腦。事實上,量子計算機的成本過高,只有大公司和政府才能負擔得起。然而,公眾仍然有機會接觸量子計算,主流雲提供商都宣佈了對量子計算的研究以及量子計算的出租服務。量子計算可能給NP完備問題帶來重大突破,例如分子模擬和最佳化邏輯問題等。這也可能意味著,只要有能力負擔量子計算機,TLS等加密的破解就不是問題。目前看來,量子計算將加速某些類別的問題,但在短期內並不會顛覆計算。量子計算真正的影響在於加速科學領域的研究(物理、化學和生物的模擬),而這反過來可能會引發其他領域的突破性進展。

量子隱形傳態似乎更有可能帶來影響到公眾的重大突破,我們能否在地球兩端(以及更遠的地方!)之間實現比光速更快的高頻寬通訊?同樣,我認為量子技術要想真正能夠影響到大眾,還有很長一段路要走。

原文連結:https://blog.container-solutions.com/10-predictions-for-the-future-of-computing

聲明:本文由CSDN翻譯,轉載請註明來源。

相關文章

關於「算力」,這篇文章值得一看

關於「算力」,這篇文章值得一看

今天這篇文章,我們來聊聊算力。 這兩年,算力可以說是ICT行業的一個熱門概念。在新聞報道和大咖演講中,總會出現它的身影。 那麼,究竟到底什麼...

世界算力簡史(下)

世界算力簡史(下)

世界算力簡史(上) 世界算力簡史(中) 今天終於要完結了…… █1980-1990:PC時代 IBM-PC和「兼容機」 上一篇,我們說到,7...

科普| 企業級SSD產業格局與主流玩家介紹

科普| 企業級SSD產業格局與主流玩家介紹

5G、人工智慧、大資料、物聯網、元宇宙等新一代資訊技術不斷發展,催生海量資料儲存與互動需求,同時也推動儲存技術持續進步。在需求增加與技術迭代...

到底什麼是算力?

到底什麼是算力?

算力的字面意思,大家都懂,就是計算能力(Computing Power)。 所謂「計算」,我們可以有多種定義。 狹義的定義,是對數學問題進行...

「曲線救國」的字節跳動

「曲線救國」的字節跳動

作者 / 喬治 Tiktok大概率是逃不開了。8月1日,據路透社訊息,字節跳動同意剝離TikTok美國業務。訊息稱,根據新提議的交易,字節跳...

年砸4000億!智慧教育,到底有啥用?

年砸4000億!智慧教育,到底有啥用?

大家好,我是小棗君。 上週,我給大家介紹了一下什麼是智慧城市(連結)。今天,我們繼續探討關於「智慧」的話題,聊聊資訊通訊技術在教育領域的應用...

到底什麼是「算力網路」?

到底什麼是「算力網路」?

引言: 前幾天,小棗君和大家聊了一下「算力」(連結)。今天,我們再接再勵,聊聊「算力網路」。 █什麼是「算力網路」 直奔主題,到底什麼是算力...

AR眼鏡走向獨立,從一個配件開始

AR眼鏡走向獨立,從一個配件開始

明敏 發自 凹非寺 量子位 | 公眾號 QbitAI AR要走遠,能長久依賴手機這副柺杖嗎?還是需要獨立形態,擁有自身的內容生態圈?這次,一...