WebAssembly 不會取代 Docker

最近有很多關於 WebAssembly 最終是否會取代 Docker 的討論。而討論的核心,往往集中在容器具備哪些優勢特性,比如可移植性、資源節約或者其他屬性之類的。按照支持者們的吹捧,容器終有一天會徹底取代虛擬機,但至少在當下,容器還沒那牛到那個程度。

Fermyon Technologies 公司 CEO Matt Butcher 告訴 The New Stack,“遙想 2014 年,當容器第一次引起人們注意時,所有的討論都是關於容器能否取代虛擬機。但經過多年實踐,我們意識這兩種技術其實是相互補充、而非相互替代。”

雖然關於 Docker 和 Wasm 如何互補的討論也不少,但這種互補性恐怕不會非常普遍。相反,Docker 似乎會堅守住分佈式應用這一核心據點,而 Wasm 則繼續攻城掠地、開拓更多新鮮用例,特別是在那些能讓 Wasm 發揮安全優勢的特定 / 極端應用場景之下。

—__1 

應用交集

Butcher 解釋道,“如果畫一張功能維恩圖,那容器和 WebAssembly 肯定會有交集。在未來幾年裏,行業會逐漸摸索出如何處理其中一部分交集。但我個人認爲,這些交集並不算太大,而其餘非交集部分將揭示出這兩種技術的協同發展方向。”

Docker 產品負責人 Jake Levirne 則在採訪郵件中表示,目前的交集用例已經不算少了,但他堅持認爲重點根本就不在於 Wasm 能否有朝一日取代 Docker 容器,二者融合纔是大勢所趨。

在 Levirne 看來,基於 Docker 的開發、測試和部署工具鏈之所以大受歡迎,依靠的就是輕鬆、易維護、可重現的應用程序交付管道,且不受具體應用程序架構的影響。他解釋道,“如今我們已經面對數百萬個預構建 Docker 鏡像,其中包括數千個官方 / 經過驗證的鏡像,足以作爲數據存儲、緩存、搜索和框架等核心服務主幹,與 Wasm 模塊配合使用。而隨着時間推移,容器運行時和註冊表也將擴展並納入對原生 Wasm 模塊的支持。實際上,這一切目前正在悄然發生。”

—__2 

優勢與不足

跟 Docker 容器一樣,Wasm 在誕生之初就擁有着確切且自適應的計算結構。它能夠適應多種不同編程語言,除了常見的 HTML 和 CSS 之外,它還能將 JavaScript(JS)、C++ 和 Rust 集成至單一運行時平臺之內,並以二進制格式執行函數。

Wasm 既可用於支持 Web 應用程序,也能擴展至 CPU 上運行的各類邊緣環境 / 雲原生平臺,包括服務網格和邊緣 Kubernetes 等場景。另外,Wasm 的歷史也不算短了,並於 2019 年被萬維網聯盟(W3C)指定爲 Web 標準,成爲繼 HTML、CSS 和 JavaScript 之後的第四項 Web 標準。

而之所以目前的競爭用例間還沒出現大量交集,主要是因爲 Docker 容器,特別是容器自身的結構和功能特性。也正是憑藉這些特性,讓 Docker 和容器成了 DevOps 領域的寵兒。如今,除了容器和 Wasm 之外,市面上還存在裸機、虛擬機、函數即服務(FaaS)等多種不同應用計算架構,未來肯定還會出現更多。

在 Levirne 看來,這意味着 “開發者在選擇代碼運行方式時,將繼續擁有更大的靈活性。容器的優勢在於提供豐富的應用執行能力,允許這些應用程序隨意使用當前 Linux 提供的全部開源和商業庫、包及工具,同時又提供了相對輕量化的隔離機制。相比之下,Wasm 的隔離方法更輕量化,但卻只適用於特定一部分純新建應用程序。換句話說,這些應用程序無法依賴以往無數開源項目的既有成果。”

容器技術在這兩大應用場景中勢頭仍然強勁,“相信這種優勢至少還能再持續幾年。” 在 Butcher 看來,“原因有二:首先,容器仍是對現有應用程序不加修改、直接打包的最佳選項。換言之,任何現有應用程序都能輕鬆進行打包、分發並以容器形式運行。其次,數據庫和持久數據存儲天然跟容器更對路。PostgreSQL、MongoDB 和 Redis 等數據服務用例都更適應傳統服務器模型,即一個進程啓動完成後,會一口氣運行數天、數月甚至數年,期間絕不中斷。在這兩點上,我認爲 WebAssembly 在很長一段時間內還發揮不出自己的獨特優勢,所以不可能成功壓倒 Docker。”

但另一方面,Wasm 也不乏證明自身價值的舞臺。Wasm 的價值核心在於面向二進制結構,因此可以直接在 CPU 層次上運行,並消除容器鏡像內包含代碼缺陷等潛在風險。

Adobe 公司高級軟件工程師 Colin Murphy 在採訪中表示,Wasm 代表的正是 “人們所說的「業務邏輯」,即用應用代碼直接構建 Web 服務產品”。以 Adobe 爲例,他們使用 Wasm 和 WASI 幫助用戶在 Adobe Sign 中籤署文檔,並在 Lightroom 中編輯圖像。但在除此以外的其他場景下,Docker“仍將主宰一切”,例如數據庫、代理和只運行 NGINX/Apache 的 Web 服務器等。

Murphy 還強調,“具體來講,任何與 WASI 基於能力的安全模型相沖突的事物,都還是得由 Docker 來處理。另外,受到安全模型或其他因素的限制,很多遺留應用程序無法被輕鬆移植至 Wasm。”

SingleStore 公司首席軟件工程師 Bailey Hayes 表示,使用用戶代碼擴展系統的方法多種多樣,Wasm 的獨到之處在於提供一種可移植且安全可靠的沙箱,能夠以接近原生的速度在進程內運行。

Hayes 解釋道,“對數據庫而言,只有迴避其他解決方案的缺點,例如數據重複、網絡通信或進程間通信,才能真正實現高性能。正因爲如此,我們才選擇 Wasm 來支持 SingleStoreDB 中的代碼引擎。”

另外,安全性也是 Wasm 的一大主要賣點。Murphy 表示,“與 Docker 相比,Wasm 的優勢主要體現在安全性、性能、模塊化和大小。而且即使是在允許的範圍內,Wasm 的要求也更嚴格一些。”

Murphy 解釋道,與 Docker 不同,“我們不能在 Wasm 上簡單構建一個巨型應用程序,把它複製到容器裏再直接丟掉生產環境運行。這麼幹也有好處,比如在運行一個堆大小達 128 GB 的 JVM 時,這樣能防止效率下降。但同時,這樣會大大提升應用程序的移植難度。畢竟 Wasm 本身就是一種語言,雖然很多語言都能被編譯爲 Wasm,但最終會受到 Wasm 範式的約束。事實證明,已經針對容器化完成了優化,或者說最沒必要移植的應用,反而是最易於移植的。而大部分不符合容器原則的應用程序反正處處受限、難以編譯。”

—__3 

展望未來

前文已經提到,Docker 容器和 Wasm 將各自孕育出能充分發揮其特徵與優勢的獨特用例。如果容器真能在幾分鐘內解決需求,沒人會閒到嘗試用 Wasm 工具來啓動 Kubernetes 集羣。

Cosmonic 公司聯合創始人兼 CEO Liam Randall 認爲,隨着 “人們越來越多爲自己的企業或業餘項目編寫應用程序和業務邏輯,未來 Wasm 的生命力將會愈發旺盛並得到廣泛認可。Wasm 更小、能夠真正跨平臺開發且輕量化程度更高,足以運行在我們在任意位置指定的任意設備之上。而體量更大、成熟度更高的工具則可能會繼續以二進制文件或者容器的形式運行——比如說 Nginx、Postgres 以及 Redis,至少從短期來看,把這些東西編譯成 Wasm 似乎也不會產生什麼特別的回報。而且對於那些需要針對數據庫之類的東西編寫應用程序的人來說,容器仍然是種很好的開發工具。Docker 加 Postgres 的組合將在可預見的未來,繼續給開發者們帶來出色的體驗。所以我估計在短期內,Wasm 將主要負責應用程序構建,而容器則負責承載各類工具和軟件。”

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/g5F6vZNIianVTYhJbUilAg