InfoQ
來自伯克利的犀利斷言：Serverless 計算將會成為云時代默認的計算范式，將會取代 Serverful （傳統云）計算模式，因此也意味著服務器 - 客戶端模式的終結。
你準備好了嗎？
引言
2009 年，伯克利以獨特的視角發布了一篇文獻，定義了云計算，十年過去了，這篇文章被引用無數，其中的觀點更是當下最好的見證：
1、按需計算的表現形式。
2、消除云用戶的前期承諾。
3、根據需要在短期內支付使用計算資源的能力。
4、規模經濟，由于許多非常大的數據中心，顯著降低了成本。
5、通過資源虛擬化簡化操作并提高利用率。
6、通過多路復用來承載不同組織的工作負載，進而提高硬件利用率。
2019 年，伯克利又以新的視角發布了一篇文獻：將云中的編程變得簡單：伯克利視角下的 Serverless 計算。 觀點同樣讓人眼前一亮：
Serverless 所提供的接口，簡化了云計算的編程，其代表了程序員生產力的又一次的變革，一如編程語言從匯編時代演變為高級語言時代。
因為 Serverless 和傳統的云計算有著本質的區別：
1、計算和存儲的解耦，彼此獨立擴展和定價。
2、將執行的代碼作為運行的對象，而屏棄了分配該段代碼所運行的資源。
3、代碼成為明碼標價的對象，而不再是運行代碼所需要的資源。
如果各位看官和我一樣，對于伯克利視角下的 Serverless 好奇的話，不妨跟隨我接下來以問答的方式來解讀一下這篇文獻：
數據中心即計算機。 —— Luiz Barroso（2007）
Serverless 計算的最佳理解是？
在任何的 Serverless 平臺，用戶只需要使用高級語言撰寫使用云功能，然后以事件來觸發運行即可，如將圖片上傳到云存儲中、將圖像縮略圖插入到數據庫表中，而所有的傳統的操作：實例選擇、實例擴展、部署、容錯、監控、日志、安全補丁等等，均由 Serverless 計算的來掌控。
Serverless 計算和傳統的云計算（serverful）有何區別？
相對于 Serverless 計算，傳統意義上的云計算已經成為了 Serverful 計算了，以下列表從開發者和系統管理員的角度分別對比了他們二者之間的區別：
特性AWS Serverless 云計算AWS Serverful 云計算程序員何時運行程序由云用戶根據事件自行選擇除非明確停止，否則會一直運行。編程語言JavaScript、Python、Java、Go 等有限的語言任何語言程序狀態保存在存儲（無狀態）任何地方（有狀態或無狀態）最大內存大小0.125~3GiB（云用戶自行選擇）0.5~1952GiB（云用戶自行選擇）最大本地存儲0.5GiB0~3600 GiB （云用戶自行選擇）最長運行時間900 秒隨意最小計費單元0.1 秒60 秒每計費單元價格$0.00000020.0000867?
0.0000867?0.4080000操作系統和庫云供應商選擇云用戶自行選擇系統管理員服務器實例云供應商選擇云用戶自行選擇擴展云供應商負責提供云用戶自己負責部署云供應商負責提供云用戶自己負責容錯云供應商負責提供云用戶自己負責監控云供應商負責提供云用戶自己負責日志云供應商負責提供云用戶自己負責
基于云環境的描述下，Serverful 計算猶如傳統底層的編程語言，如匯編程序；而 Serverless 計算猶如高級的編程語言，如 Python。前者開發者需要考慮每一個細節，到 CPU 寄存器這樣一個級別，而后者開發者只需要考慮要實現的功能即可。
Serverless 之所以成為可能的基礎條件有哪些？
1、Serverless 計算是在 PaaS 和原來模式的之上的重要創新。
2、基于 VM 的隔離技術，如 Firecracker 、gVisor 等技術的成熟。
3、允許云用戶攜帶運行程序所需要的庫。
4、BaaS 的發展，如對象存儲的不斷完善。
5、容器技術、Kubernetes 項目的崛起。
6、邊緣計算的迅猛發展需求
伯克利對 Serverless 的大膽預言是什么？
Serverless 將會在接下來的十年，迅速的被采用，將會得到飛速的發展。
1、新的 BaaS 存儲服務會被發明，以擴展在 Serverless 計算上能夠運行更加適配的應用程序類型。 這樣的存儲能夠與本地塊存儲的性能相匹配，而且具有臨時和持久可供選擇。
2、比現有的 x86 微處理器更多的異構計算機。
3、更加安全、易用的編程，不僅具有高級語言的抽象能力，還有很好的細粒度的隔離性。
4、基于 Serverless 計算的價格將低于 Serverful 計算，至少不會高于 Serverful 計算。
5、Serverless 將會接入更多的后臺支撐服務，如 OLTP 數據庫、消息隊列服務等。
6、Serverless 計算一旦取得技術上的突破，將會導致 Serverful 服務的下滑。
7、Serverless 將會成為云時代默認的計算范式，將會取代 Serverful 計算，因此也意味著服務器 - 客戶端模式的終結。
Serverless 計算的軟件棧架構概覽
Serverless 介于基礎云平臺和應用程序之間，旨在簡化基于云的編程開發，Cloud Functions （通常稱之為 FaaS）提供通用的計算，輔以專門的后端即服務（BaaS）等生態系統，如對象存儲、Key-Value 數據庫等。
Serverless 目前應用的場景如何？
來自 2018 年的一個調查顯示：
百分比用戶場景32%web 和 API 服務21%數據處理，如批處理的 ETL17%整個第三方的服務16%內部 tooling8%聊天機器人，如 Alexa Skills（Alexa AI 助手 SDK）6%物聯網
對五類典型應用的深度分析：
應用程序描述挑戰解決辦法花銷比較實時視頻壓縮（ExCamera）扔到云中的視頻解碼對象存儲太慢，無法支持細粒度的通信 ; 功能太粗糙，無法完成任務。功能對功能以避免對象存儲；以功能調度而不是任務。比基于虛擬機快 60 倍，但是錢只花了 1/6。MapReduce大數據處理（100TB 排序）由于對象存儲延遲和 IOPS 限制，擴展成為問題使用低延遲存儲，高 IOPS比虛擬機快 1%，節省 15% 的費用線性代數計算（Numpy-wren)大規模線性代數計算對象存儲的低延遲、難以實現客戶端的廣播問題。使用低延時高吞吐的對象存儲，比原來慢了 3 個數量級，CPU 的消耗降低 1.26 到 2.5 倍。機器學習 pipeline(Cirrus)大規模的機器學習缺乏快速的存儲，難以實現廣播、聚合問題。使用低延遲存儲，高 IOPS比虛擬機快 3~5 倍，比原來貴 7 倍數據庫（Serverless SQLite）應用程序的主要狀態（OLTP）缺乏共享內存，對象存儲具有高延遲，缺乏對入站連接的支持。如果寫入需求低，共享文件系統可以工作。TPC-C 基準，要比原來的快 3 倍，讀取比例匹配但寫入不匹配。
對 Serverless 計算的期待？
抽象層：更多的資源調度、增加數據依賴功能
系統：高性能、經濟實惠、透明配置的存儲，最小化啟動時間，協調服務
網絡：實現更高吞吐量的通信
安全：隨機的調度、物理隔離、細粒度的安全上下文、
體系結構：異構性、價格下調、更方便的管理
Serverless 計算目前有被人們吐槽的地方？
在分析了五大典型（實時視頻解碼、MapReduce、大規模線性代數計算、機器學習訓練、數據庫）應用案例之后，得出如下幾個結論：
1、存儲空間不足以進行細粒度操作
2、缺乏細粒度的協調
3、標準通信模式的性能不佳
4、啟動的延遲性
是什么吸引著大家去追求 Serverless 計算方式？
對于云用戶來說：
1、不需要任何的操作云基礎設施、部署等知識，關注功能即可
2、更加容易編寫應用程序是最主要的動力
3、更短的運行時間，毋須關心內存的大小，無狀態的天然特性
4、省錢
對于云提供商來說：
1、減少對 X86 服務器的采用，可有效節省成本。
2、對計算新的抽象，意味著未來的無限可能性
謬誤和陷阱
本章是向 Hennessy and Patterson 二位的風格致敬。鑒于本文只是讀論文的解讀，所以不會翻譯所有的內容，這里僅拋磚引玉，講述兩個非常有趣的答復：
謬誤 ：Cloud Functions 無法處理需要可預測性能的極低延遲應用程序。
Serverful 計算，即服務器實例對于低延遲應用程序的處理，是它們始終處于啟動狀態，因此它們可以在收到請求時快速回復請求。 那么，照葫蘆畫瓢，如果 Cloud Functions 的啟動延遲對于給定的應用程序來說不夠好，可以使用類似的策略：通過定期運行它們來 Cloud Functions 進行預熱，從而確保在任何給定時間都能夠及時的響應，進而滿足傳入的請求。
陷阱：Serverless 計算會導致無法預料的成本
這種純粹意義上按代碼運行付費的模式，其實是大家對于這樣新的計費模式的不適應罷了，尤其是大型公司的預算考慮，相信隨著時間的推移，一旦人們了解了自己的業務以及有了一些歷史數據之后，就會適應這樣的計算模式的，一如對于如電力這樣的計費模式。
筆者能力所限，加上論文論斷式的風格，最后強烈建議各位看官請移步伯克利網站下載論文，進行進一步的深度閱讀！尤其是引用的材料。
論文鏈接：
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
