譯者 | 蔡柱梁
還記得大型機嗎?無服務器就好比如:我們擁有這臺機器,你來我這里租借。創新往往都是在踩在巨人肩膀上誕生!
分時度假是一種源于歐洲的度假模式,就是把酒店或度假村的一間客房或一套旅游公寓,將其使用權分成若干個周次,按10至40年甚至更長的期限,以會員制的方式一次性出售給客戶,會員獲得每年到酒店或度假村住宿7天的一種休閑度假方式。并且通過交換服務系統會員把自己的客房使用權與其他會員異地客房使用權進行交換,以此實現低成本的到各地旅游度假的目的。
回過頭看,無服務器就是新的分時度假!
我們都有健忘癥。當我與年輕的開發人員談論過去的技術時,我經常會得到茫然的目光。公平地說,有些是因為我有點“緊張”或“怪異”,但有些是因為年輕的技術人員并不了解過去的技術。
舉個例子:有些年輕的技術人員根本不清楚什么是兩端提交(2 Phase Commit)。難道是事務管理已經不需要了嗎?
銀行是否不再需要一致性?如果你不在“同一頁”上,該技術通過在不同的服務器之間傳輸事務上下文來工作。因此,一臺服務器上的提交是一個多階段過程,幾乎可以保證所有服務器都成功或作為一個服務器回滾。這是相當驚人的,實際上效果相當好(顯然有一些警告)。令人驚訝的是,這是通過方法調用實現的。你不需要做任何事,即使在完全不同的服務器上調用遠程方法,它也能好好工作。
幾年前,我與銀行業的一家叫 Node-based 的初創公司交談。他們表示,銀行對與Node合作非常開放。我知道他們在更“成熟”的環境中重寫他們的東西。當我使用一些“較新”的工具,如Node時,我總是對缺少的基本功能感到驚訝。當然,如果你不把我們需要的一切都融入其中,它會更簡單、更小。當您放棄核心功能時,很容易構建簡單的東西。
2010 年代的 NoSQL 戲劇
早在 1999 年,我正在組建自己的咨詢公司,一位朋友讓我見見他的老板。我去了這個辦公室,“老板”說他有一個沒有人想到的最驚人的想法。他們有資金,將在 6 個月內推出產品,并在第一天就向 100 萬用戶推出!
我:好的。什么想法?
他:我會在你報名為我們工作后告訴你。
我:我會簽署 NDA(NON-DISCLOSURE AGREEMENT,即不公開協議)。
他:不。這個主意太好了。那些保密協議一文不值。你注冊然后…
不知道為什么,我居然能夠頂住為這家公司工作的誘惑。大概一年后,他們顯然沒有推出,但我的咨詢公司做得很好。朋友又打電話給我了。這一次他們需要產品方面的幫助,所以我以咨詢的身份去那里幫助他們。
他們的想法是在網站中內置一個聊天應用程序,這樣網站的訪問者就可以互相聊天。一個競爭對手已經推出,我正在咨詢其他幾家具有相同想法的公司。他們轉而專注于與電子商務相關的聊天。但我離題了……
他們的系統表現非常糟糕。一個用戶的速度就像黏了蜜糖的螞蟻一樣慢。顯然,CEO 堅持他們需要在第一天就能支持 100 萬用戶(正如他告訴我的那樣)。他們將這一點傳達給Oracle公司,Oracle說他們需要一個由三臺服務器組成的集群來支持這個容量。然后他們與一家面向對象的數據庫供應商進行了交談,后者承諾他們可以用一臺機器處理 100 萬用戶。所以他們全神貫注于面向對象的數據庫。當我對此表示震驚時,他們聲稱他們的數據非常“面向對象”,因為每個用戶都可以擁有多個項目……呃。
他們不了解事務邊界,存儲代碼與所有代碼混合在一起,而且速度很慢。這是不可靠的,無法理解。您可能不記得面向對象的數據庫時期,但它是 2010 年代席卷我們行業的 NoSQL 時尚的先驅。在擔任顧問的那段時間里,我重新觀看了這個故事的重播。這一次大多數公司都成功推出了。
但后來他們發現擁有非結構化數據并不是萬能的。與僅使用良好的緩存和經過良好調整的 SQL 相比,他們在性能方面獲得的好處是微不足道的。部署故事非常復雜,輔助工具可能永遠無法達到我們在 SQL 世界中所擁有的水平。
需要明確的是:NoSQL有自己擅長的領域,但是這些數據庫常見的用途并不是很好,并且源于 RDD(恢復驅動開發)。這是我們這些已經在街區附近轉過幾次的人一遍又一遍地看到的模式:
? 舊技術笨重復雜
? 人們發明了一些干凈簡單的東西
? 忘記舊技術的存在
? 新東西過于簡單化,并沒有做很多基本的東西
? 重塑這些復雜性
? 新的東西變成了需要重新發明的舊的和笨重的復雜性……沖洗/重復
無服務器是新的大型機
在過去的一個月里,我做了很多無服務器的工作,我覺得這是一個很大的倒退。這是重蹈覆轍我們在 PaaS 上遇到的問題。它實際就是一個大型機。過去,我們曾經為在共享使用的大型機上運行工作付出代價。這有點像??虛擬化環境??,但想法相似:我們不擁有該環境。可以說這對于云 SaaS 也是如此,但無服務器將這個概念帶到了很遠的地方。
甚至調試體驗也很糟糕。我們沒有對我們的代碼或基本應用程序邏輯的基本控制。我正在努力弄清楚為什么人們將它用于基本任務之外。
我能想到一個很好的用例:webhook。獲取 webhook 的管道代碼總是很痛苦。他們不經常觸發,處理它是一件苦差事。使用無服務器功能將內容添加到數據庫并完成工作可能非常簡單。由于無論如何都很難調試回調,因此無服務器中糟糕的調試體驗并不是一個巨大的障礙。但是對于其他所有用例,我絕對感到困惑。
人們花費大量時間檢查和測量吞吐量,但僅使用一臺稍大的服務器,并且只有本地調用會產生超出您可能需要的吞吐量。沒有我們陷入的所有供應商捆綁。使用 Linode、Digital Ocean 等托管會節省很多錢。在上市時間方面,僅使用緩存和快速本地工具將比您可以在云中構建的任何東西容易得多。
容器是一個很好的進步,它們讓這一切變得簡單多了,但我們會被為了使用容器而帶來的復雜性累垮,比如K8S。不要誤會我的意思。K8S很棒。但我們 98% 的人并不真正需要它,也不應該使用它。如果你是一家小型的創業公司,Kubernetes 是在浪費你的時間和精力。
回到 Java 和 Rust
Java 就是一個在“健忘方面”做得很好的例子。我們有 Smalltalk,它很棒。當 Java 剛出現時,它是一種具有怪異 C 語法風格的劣質解決方案。Java 在 Smalltalk 和 C++ 中拋棄了許多偉大的想法。它采用了一些有爭議的想法(檢查異常、原語等)。然而它成功了。它吸引了人們的注意力;它能夠利用這一點。
它最初是一種輕量級語言,可以丟棄其他平臺添加的所有垃圾和過度工程。現在看看,再也沒有人將其描述為“輕量級”。開發人員正忙于創建更輕、更簡單的語言來抱怨 Java 的錯誤。成功會讓他們回到我們開始的地方。一種成長太多的輕量級語言。Java 目前處于應有的位置。這是一個好的重寫的少數例子之一。
Rust 似乎也是少數例外之一。它以一種全新的方式重新發明了 C。很難說它是否能長期生存。但毫無疑問,它需要在此過程中承擔很多復雜性。
有意識的重塑
是什么讓對現有語言或工具的重新發明成功贏取大眾市場,又是什么讓這些工具被擱置一旁?
SQL 起死回生,再次受到新創業公司的青睞。對于 C++ 則不能這樣說。它們有何不同?
盡管缺少我們在 JVM 世界中擁有的基本功能,但 Node 和 Python 仍然很受歡迎。那是怎么回事,他們會維持這種受歡迎程度嗎?他們會把這些東西加回去嗎?
直到青少年時期,我們的大腦不斷地增加突觸。在我們十幾歲的時候,我們把它們砍掉了。一種理論是,這是我們作為青少年所經歷的所有變化的根源。我們需要斷開不再為我們工作的東西。否則,我們只會學習父母所知道的。我們不能通過犯自己的錯誤來改進。再次嘗試那一代人失敗的事情。
結果,我們重復了錯誤,犯了一些新的可怕的錯誤。我們也取得了一些驚人的飛躍和發現。這是創新起飛的地方,工程也是如此。
我們如何區分:青少年焦慮與光明的新方向?
老實說,我們不能。作為一個年長者,當我第一次看到這些東西時,我覺得很多東西都很愚蠢。我們已經嘗試過這些事情并且失敗了。為什么要重復那個錯誤的方向?這就是創新所在。但是,如果我們仔細觀察成功的嘗試,我們可以看到對他們有用的東西。
Java 并非旨在結束 C++。當然,這可能是一個幻想。但高斯林設計它是為了簡單和輕小。要解決非常狹窄的利基市場,請關注安全性、規模和網絡。
Rust 并非旨在終結 C。它旨在使 Firefox 等項目更加穩定和高性能。
我認為,當我們最初將自己限制在一個非常小而狹窄的用例時,二次發明就像任何初創公司一樣,效果很好。通過這樣做并保持最初的關注點,我們可以建立一些好的東西,然后實現偉大的飛躍。
譯者介紹
蔡柱梁,51CTO社區編輯,從事Java后端開發8年,做過傳統項目廣電BOSS系統,后投身互聯網電商,負責過訂單,TMS,中間件等。
原文標題:??Serverless Is the New Timeshare??,作者:Shai Almog