加州大學伯克利分校繼 2009 年發佈 《The Berkeley View on Cloud Computing》一舉撥開雲計算迷霧，十年後又一次發佈了 《A Berkeley View on Serverless Computing》，試圖再次指出下個 10 年雲計算的發展方向及挑戰，並斷言無服務計算將成爲雲時代的默認計算範式，在很大程度上取代 serverful 計算，從而結束客戶機-服務器時代。由此可見無服務計算（ Serverless Computing） 這一新雲計算範式所具有的里程碑意義。
如下圖所示，是 Google Trend 總結的過去五年中關鍵詞 “Serverless” 和 “Microservices” 的搜索趨勢，發現在 2017 年 Serverless 的搜索趨勢開始超過微服務，也從用戶搜索層面表明無服務越來越多的進入大家的視野。
本文從伯克利這篇文章入手，爲大家揭開 Serverless 神祕的面紗。
以下長文預警。。。
以下長文預警。。。
廣告時間：
無意中發現了一個巨牛的人工智能教程，忍不住分享一下給大家。教程不僅是零基礎，通俗易懂，而且非常風趣幽默，像看小說一樣！覺得太牛了，所以分享給大家。點這裏可以跳轉到教程。
摘要
無服務雲計算幾乎了處理所有系統管理操作，使得程序員能夠更加容易地使用雲。 無服務計算提供了一個接口極大地簡化了雲編程，並且代表了從彙編語言到高級編程語言的轉變。 本文簡要介紹了雲計算的歷史，包括了 2009 年伯克利對雲計算的預測，揭示了無服務計算的 motivation，描述了擴展無服務當前限制的應用程序，然後列出了發揮無服務計算潛力所遇到的阻礙和機會。 就像 2009 年的論文確定了雲的挑戰並預測它們將得到解決，以及雲會越來越被廣泛使用一樣，我們預測這些問題是在未來可被以解決的，並且無服務計算將成爲雲計算未來的主導。
1 Introduction to Serverless Computing
The data center is now the computer.
Luiz Barroso (2007)
在 2009 年，爲了幫助解釋雲計算所帶來的優勢，伯克利在 《The Berkeley View on Cloud Computing》一文中提出了六個潛在優勢：
- 可以按需使用無限量的計算資源
- 消除運用戶的預先承諾
- 根據實際需要支付短期使用計算資源的費用
- 規模經濟顯著降低了成本，因爲數據中心非常大
- 通過資源虛擬化技術簡化了操作病提高了資源利用率
- 通過多路複用的方式運行來自不同組織的負載，提高硬件資源利用率
在過去的這十年中，我們可以看到這些優勢大部分都實現了，但是雲用戶仍然要忍受着複雜操作的壓力，許多負載仍然沒有從高效的多路複用中收益。這些不足主要於未能實現的兩個潛在優勢有關，雲計算雖然減輕了用戶對物理資源（即基礎設施）的管理，但是他們需要管理大量的虛擬資源。多路複用對於批處理類型的負載（如 MapReduce 或高性能計算）非常有效，這些負載可以充分利用分配給它們的實例，但是對於有狀態的服務並沒有那麼有效，例如將企業的軟件移植到雲計算上時（如數據庫管理系統）。
在 2009 年，有兩種相互競爭的雲虛擬化方法，正如這篇論文中所解釋的：
Amazon EC2 is at one end of the spectrum. An EC2 instance looks much like physicalhardware, and users can control nearly the entire software stack, from the kernel upward… At the other extreme of the spectrum are application domain-specific platforms suchas Google App Engine … enforcing an application structure of clean separation between astateless computation tier and a stateful storage tier. App Engine’s impressive automaticscaling and high-availability mechanisms … rely on these constraints.
Amazon EC2 是一個極端，EC2 實例看起來很像物理硬件，用戶幾乎可以控制整個軟件棧，從內核向上… 另一個極端是針對於特定領域的應用平臺，比如 Google App Engine… 在無狀態計算層和有狀態存儲層之間強制使用分離的應用程序結構，App Engine 的自動擴展和高可用性機制… 依賴這些約束。
最終市場使用了 Amazon 這種針對雲計算的 low-level 虛擬機方式，所以 Google、Microsoft 和其他雲計算公司也提供了相似的接口。我們相信這種 low-level 虛擬機成功的主要原因是，早起的雲計算用戶希望在雲中可以重新創建一個與本地計算機上相同的計算環境，以簡化將其負載遷移到雲上的工作。很明顯，這種實際需求比爲雲重新編寫新的程序更重要，尤其是在當時雲計算能否成功尚不明確的情況下。
這種選擇的缺點是，開發人員必須自己管理虛擬機，所以要麼成爲系統管理員，要麼與它們一起設置環境。表1列出了在雲中操作時必須管理的問題，這一長串需要負責的底層虛擬機管理問題，促使那些只使用簡單化應用的客戶向雲服務商提出新要求，希望能有更簡單的方式來運行這些簡單應用。例如，假設應用希望將圖片從手機端應用發送到雲上，這需要創建極小的圖片並將其放在 web 上，完成這個任務可能只需要幾十行 JavaScript 代碼，這與設置適當的服務器環境來運行這段代碼相比，這個代碼的開發是很微不足道的。
認識到這些需求後，Amazon 在 2015 年推出了一個名爲 AWS Lambda service 的新服務。Lambda 提供雲函數，這引起了大家對無服務計算的廣泛關注。儘管無服務可以說是一個很矛盾的說法，因爲你仍然使用服務器去進行計算，這個名字之所以被保留下來，大概是因爲它表明用戶只需要編寫代碼，服務器供應和任務管理問題都由服務提供商來負責。儘管雲函數打包爲 FaaS（Function as a service），代表了無服務器計算的核心，但是雲平臺還提供了專門的無服務器框架，以滿足特定的程序需求，如 BaaS（Backend as a Service）。簡單地說，無服務計算定義如下：
Serverless Computing = FaaS + BaaS。
在我們的定義中，要將服務視爲無服務的，他必須能夠自動擴縮容，並且根據實際使用情況計費，在本文的其餘部分中，我們將重點討論雲函數的出現、演化和未來。雲函數是當今無服務計算的通用元素，它爲雲提供了簡化的通用編程模型。
接下來，我們將定義無服務計算（serverless computing），與十年前的 《The Berkeley View on Cloud Computing》文章一樣，我們後面會列出實現無服務計算的承諾所面臨的挑戰和研究機會，雖然我們不確定哪種解決方案會勝出，但是我們相信所有問題最終都會得到解決，從而使無服務計算稱爲雲計算的新面貌。
2 Emergence of Serverless Computing
在任何無服務平臺，用戶只需要用高級語言編寫雲函數，選擇觸發雲函數運行的事件就可以了，例如加載一個鏡像到雲存儲中，或者向數據庫添加一個很小的圖片，讓無服務系統來處理其他所有事情，如選擇實例、擴縮容、部署、容錯、監控、日誌、安全補丁等等。表2 總結了無服務和傳統方式之間的差異，本文將其稱爲 serverful 雲計算。需要注意的是，這兩種方法表示 function-based／server-centered 的計算平臺的端點，而 Kubernetes 之類的容器編排框架則表示中間層。
圖1 說明了 serverless 如何通過簡化雲資源的使用來簡化應用程序的開發。在雲上下文中，serverful 計算類似於使用低級彙編語言進行編程，而無服務計算類似於使用高級語言（例如 python）進行編程。計算例如 c = a + b 的簡單表達式的彙編程序員必須選擇一個或者多個寄存器，將值加載到這些寄存器中，執行運算，然後存儲結果。這反映了 serverful 雲編程的幾個步驟，首先提供資源或者標識可用的資源，然後用必要的代碼和數據加載這些資源，執行計算，返回或者存儲結果，最終管理資源釋放。無服務計算的目標是爲雲程序員提供類似於高級編程語言的便捷性。無服務計算與高級編程環境的其他特性也有相似之處，例如自動內存管理使程序員不用再管理內存資源，而無服務計算使程序員不用再管理服務器資源。
準確來說，serverless 和 serverful 計算有三個關鍵的不同之處：
- 將計算與存儲解耦。存儲和計算資源是分開提供的，相當於這兩種資源的分配和計價都是獨立的，通常來說存儲資源是由一個獨立的雲服務來提供的，並且計算是無狀態的。
- 執行代碼而不需要管理資源分配。與傳統雲計算用戶需要請求資源的方式不同，serverless 是用戶提交一段代碼，雲會自動給這段代碼分配資源並執行。
- 以實際使用的資源量付費，而不是根據分配的資源數。serverless 計費是根據一系列與執行相關的因素來計算的，例如代碼的執行時間，而不實根據雲平臺，例如分配的 VM 的大小和數量。
接下來，根據這些區別，我們會解釋 serverless 在過去和現在與類似的產品會有何不同。
2.1 Contextualizing Serverless Computing
要使無服務計算成爲可能，需要突破哪些技術呢？一些人認爲，無服務計算只是對以前產品的重新命名，可能是對平臺即服務（Platform as a Service，PaaS）的一個概括。其他人可能會指出，上世紀 90 年代流行的共享 web 主機環境提供了許多無服務計算所能提供的功能。例如，它們有一個無狀態編程模型，允許多租戶、對可變需求的彈性響應和一套標準化的函數調用 API、公共網關接口（CGI），甚至允許直接部署用 Perl 或 PHP 等高級語言編寫的代碼。Google 最初的 App Engine，它也允許開發者直接部署代碼，同時將大部分的操作交由雲提供上來進行，但是在無服務計算流行起來前的那幾年，基本上是不被市場接納的。我們相信，相對於 PaaS 和其他以前的模型，無服務計算代表了重大的創新。
當下的無服務計算與之前的產品不同點在於：更好的自動擴縮容、強隔離、平臺靈活性和服務生態支持，在這些不同點中，AWS Lambda 提供的自動擴縮容標誌着與之前產品最大的不同。Serverless 平臺跟蹤應用的負載並進行自動擴縮容做的比 serverful 好很多，可以在需要時快速響應擴容，並在沒有需求的情況下將資源一直縮容到零。它以一種更加細粒度的方式管理，當其自動擴縮容服務按時間計費時，它提供了 100ms 粒度的最小增長。當峯值時刻離開時，它按照代碼實際執行的時間進行收費，而不是按照位程序預留的資源，這一區別確保了雲提供商在自動擴縮容上風險共擔，從而提供了確保有效資源分配。
無服務計算依賴於強大的性能和安全隔離，使多租戶共享硬件成爲可能。VM 類似的隔離是當前雲函數下多租戶硬件共享的標準，但是因爲 VM 配置需要較長的時間，爲了縮短這個時間，無服務計算提供商使用複雜的技術來加快函數運行環境的創建。AWS Lambda 中使用的方法是維護一個熱的 VM 實例池，以及維護一個用於運行函數實例的池子，以服務於未來服務的調用。資源的生命週期管理和多租戶下負載打包是無服務計算中提高利用率的關鍵技術，我們注意到，最近一些工作旨在通過利用容器、unikerkernel、操作系統庫或語言 VM 來介紹提供多租戶隔離的開銷。例如谷歌已經宣佈 gVisor 已經應用在 App Engine、Cloud Functions 和 Cloud Engine，Amazon 發佈了針對 AWS Lambda 和 AWS Fargate 的 Firecracker VMs，並且 CloudFlare Workers 無服務計算平臺使用 Web 沙盒技術提供了多租戶之間 JavaScript 函數之間的隔離。
其他一些特性也幫助無服務計算獲得了成功。通過允許用戶自帶庫，無服務計算可以支持比 PaaS 服務更廣泛的應用程序。無服務計算運行在現代數據中心中，其運行規模比之前的共享 web 主機環境要大得多。如第1節所述，雲函數（FaaS）推廣了無服務計算範例，然而，值得承認的是，他們的成功在一定程度上歸功於公有云（如 AWS S3 等服務）誕生以來就存在的 BaaS 產品。在我們看來，這些服務是特定領域的、高度優化的無服務計算實現，雲函數以更加通用的形式表示無服務計算。通過比較幾個服務的編程接口和成本模型，我們在表3中總結了一個圖。
在討論無服務計算時，一個常見的問題是它如何與部署微服務的 Kubernetes “容器編排” 技術相關聯。與無服務計算不同，Kubernetes 是一種簡化的服務器計算管理的技術，由於多年來 Google 內部的開發和使用，它得到了快速的發展。Kubernetes 可以提供短期的計算環境，比如無服務計算，並在硬件資源、執行時間和網絡通信方面有更少的限制。它還可以將原本爲內部使用而開發的軟件完全部署到公有云上，而無需進行任何修改。在另一方面，無服務計算引入了一個範式轉變，完全將操作責任轉交給服務提供商，使得更細粒度的多租戶下的多路複用成爲可能。託管的 Kubernetes 產品，如 Google Kubernetes Engine（GKE）和 AWS Elastic Kubernetes Service（EKS）提供了一箇中間地帶：用戶不需要考慮 Kubernetes 的操作管理，同時爲開發人員提供了配置任意容器的靈活性。託管式的 Kubernetes 服務和無服務計算之間的一個關鍵區別是計算模型，前者按照預留的資源收費，而後者按照函數執行時間收費。
Kubernetes 也非常適合混合應用程序，其中一部分運行在本地硬件上，另一部分運行在雲中。我們的觀點是，這種混合應用程序在向雲的過渡中是很有意義的，然而從長期來看，我們認爲雲的規模經濟、更快的網絡貸款、不斷增加的雲服務以及通過無服務計算簡化雲管理，降低此類混合應用的重要性。邊緣計算是後 PC 時代雲計算的合作伙伴，雖然我們在這裏關注的是無服務計算將如何改變數據中心中的編程方式，但是邊緣計算也具有潛在的影響，一些 Content Delivery Network（CDN）運營商提供了在接近用戶的設施中之行無服務函數的能力，無論用戶可能在那裏，AWS IoT Greengrass 甚至可以在邊緣設備中嵌入無服務執行。
現在我們已經定義了無服務計算，並介紹了其上下文，讓我們看看爲什麼它對雲提供商、雲用戶和研究人員具有吸引力。
2.2 Attractiveness of Serverless Computing
對於雲服務提供商來說，無服務計算促進業務的增長，因爲其使得雲計算更容易編程，進而有助於吸引新客戶並幫助現有客戶更多地使用雲計算。例如，最近的調查發現，大約 24% 的無服務計算用戶是雲計算的新用戶，30% 現有的 serverful 用戶也使用了無服務計算。此外，短的運行時間、較小的內存佔用和無狀態特性使得雲提供商更容易找到那哪些未使用的資源來運行這些任務，從而改進了資源複用。雲提供商還可以利用不太流行的計算機（實例類型由雲提供商決定），比如對 serverful 雲客戶吸引較小的舊服務器，這兩項優點都可以最大化現有的資源並提高收益。
用戶可以從編程效率的提高中獲益，而且在許多情況下還可以節約成本，這是底層服務器利用率提高的結果。即使無服務計算可以讓客戶更高效，Jevons paradox 建議他們增加對雲的使用，而不是減少，因爲更高的效率將通過增加用戶來增加需求。無服務也從 x86 機器代碼（有99%的雲機器使用 x86指令集）提升到更高級的編程語言，這有助於計算機體系結構的創新。如果 ARM 或 RISC-V 可以提供比 x86 更好的性價比，那麼無服務計算使得更改指令集更容易，雲服務提供商甚至可以接受面向語言優化的研究和特定領域的體系結構，尤其是針對編程語言的加速，例如 Python，將在第四章進行介紹。
雲用戶更加喜歡無服務計算，因爲新手可以在不需要理解雲基礎設施的前提下部署函數，並且老用戶可以節省出部署的時間並聚焦於應用本身的問題。無服務計算可以節省開支因爲函數只有在事件發生時纔會計費，而且細粒度的計費（通常是 100 毫秒）意味着用戶只需要支付他們實際使用的部分而不是爲他們預留的部分。表4展示了當今最流行的無服務計算。
由於無服務計算是一種新的通用計算抽象，並且有望成爲雲計算的未來，因此無服務計算尤其是雲函數深深地吸引了研究人員的注意，而且有很多機會可以提升當前無服務計算的性能和克服一些當前的限制。
3 Limitations of Today’s Serverless Computing Platforms
無服務雲函數已經成功地用於幾類負載，包括 API 服務、事件流處理和有限的 ETL（見表3）。爲了弄清楚什麼阻礙了無服務計算支持更多通用的負載，我們試圖創建無服務版本的應用，並且研究別人發佈的例子，這並不代表當前無服務計算生態外的其他技術，它們只是一些實例，用於發現可能阻止其他應用轉換爲無服務版本的常見缺點。
在本章中，我們概述了五個研究項目，並討論了阻礙現有無服務計算平臺實現最好性能的障礙，即在相同負載下匹配 serverful 雲的性能。我們特別關注使用通用雲函數進行計算的方法，而不是大量依賴於其他特定應用程序的無服務產品（BaaS），然而在最後一個示例 Serverless SQLite 中，我們定義了一個使用場景，該用例與 FaaS 的映射非常糟糕，因此我們得出結論，數據庫和其他狀態較重的應用將保持 BaaS 的狀態。
有趣的是，即使這種折中的應用組合也暴露了類似的弱點，我們在描述應用程序之後列出了這些弱點，表5總結了這五個應用程序。
ExCamera：實時視頻編碼。ExCamera 旨在爲向 YouTube 等網站上傳視頻的用戶提供實時編碼服務，根據視頻的大小，現在的編碼解決方案可能需要幾十分鐘，甚至幾個小時。爲了保證實時編碼，ExCamera 並行處理編碼中“慢”的部分，連續執行“快”的部分，ExCamera 公開他們內部的視頻編碼器和解碼器，允許使用純函數語義執行執行編碼和解碼任務，特別是，每個任務都將內部狀態和視頻幀作爲輸入，並將修改後的內部狀態作爲輸出。
MapReduce。分析框架如 MapReduce、Hadoop 和 Spark 都已經傳統地部署在集羣中，雖然一部分分析類負載正在轉向無服務計算，但這些負載主要由只包含 map 的作業組成，下一步就是支持成熟的 MapReduce 作業。這種往 Serverless 轉變背後的驅動力之一就是利用無服務計算的靈活性，以有效地支持在執行過程中資源需求差異很大的作業。
Numpywren：線性代數。大規模線性代數計算傳統上部署在超級計算機或者由高速、低延遲網絡連接的高性能計算集羣上，考慮到這段歷史，無服務計算最初看起來不太合適，然而，無服務計算對於線性代數計算仍然有意義，有兩個主要原因：1）對許多非 CS 科學家來說，集羣管理師一個很大的障礙；2）在計算過程中，並行度可能會有很大的變化。提供一個固定大小的集羣要麼會降低作業執行的速度，要麼會使得集羣資源沒有得到充分地利用。
Cirrus：機器學習訓練。機器學習研究人員傳統上使用 VM 集羣來完成 ML 工作流中的不同任務，比如預處理、模型訓練和超參數調優。這種方式的一個挑戰是，這個訓練的不同階段需要的資源數明顯不同，與線性代數算法一樣，固定的集羣大小將嚴重影響作業的運行速度和集羣的資源利用率，無服務計算可以通過使每個階段都可伸縮以滿足其資源需求來解決這一挑戰，此外，它還將開發人員從集羣管理中解放出來。
Serverless SQLite：數據庫。各種自動擴縮容的數據庫服務已經存在，但是爲了更好地理解無服務計算的侷限性，理解是什麼使數據庫負載難以實現使很重要的。在上下文中，我們考慮第三方能否直接使用雲函數實現一個無服務數據庫。一個解決方案是在雲函數中運行常見的事務數據庫，如 PostgreSQL、Oracle 或者 MySQL。然而這馬上就遇到了一些挑戰，首先無服務計算沒有內置的持久性存儲，因此我們需要利用一些遠程持久性存儲，這會帶來較大的延遲；其次，假設這些數據庫是面向連接的協議，例如數據庫作爲服務器運行，接受來自客戶機的連接，這些假設與現有的雲函數運行在網絡地址翻譯器之後，因此不支持傳入的連接相矛盾；最後，雖然許多高性能數據庫依賴於共享內存，但云函數是獨立運行的，因此不能共享內存，雖然無共享的分佈式數據庫不需要共享內存，但它們希望節點保持在線並可直接尋址。所有這些問題都對在無服務計算的基礎上運行傳統數據庫軟件或實現相同的功能提出了重大挑戰，因此我們希望數據庫仍然保留 BaaS。
這些應用程序希望使用無服務計算的一個關鍵原因是細粒度的自動擴縮容，因此資源利用率與每個應用程序的不同需求緊密匹配，表5總結了這五個應用程序的特徵、挑戰和解決方案，接下來我們將使用它們來確定當前無服務計算狀態中的四個限制。
3.1 Inadequate storage for fine-grained operations
無服務平臺的無狀態特性使得很難支持具有細粒度狀態共享需求的應用程序，這主要是由於雲提供商提供的現有存儲服務的限制，表6總結了現有云存儲服務的屬性。
對象存儲服務（如AWS S3、Azure Blob Storage 和 Google 雲存儲）都具有很高的可伸縮性，並且提供廉價的長期對象存儲，但是具有較高的訪問成本和訪問延遲，根據最近的測試，所有這些服務讀取或寫入小對象至少需要10毫秒。關於 IOPS，在最近限制增加之後，S3 提供了高吞吐量，但也帶來了高成本，維持 10 萬個 IOPS 的成本爲 30 美元／分鐘，比運行 AWS ElastiCache 實例要高 3 到 4 個數量級。這樣的 ElastiCache 實例提供了更好的性能和毫秒級的讀寫延遲，並且每個實例都配置了超過 100K IOPS 來運行單線程的 Redis 服務器。
鍵值數據庫提供了高 IOPS，例如 AWS DynamoDB、谷歌雲存儲，但是價格很高，並且需要很長的時間來進行擴容。最後，儘管雲提供商提供基於流行的開源項目（如 Memcached 或 Redis）的內存存儲實例，但它們不具備容錯能力，也不像無服務計算平臺那樣能夠自動擴縮容。
如表5所示，在無服務基礎設施上構建的應用程序需要具有透明供應的存儲服務，這相當於計算資源的自動擴縮容。不同的應用程序對持久性和可用性可能會有不同的要求，並且在延遲或者其他性能指標方面有所不同，我們認爲這需要開發臨時的和持久的無服務存儲選項，我們將在第四章中進一步討論。
3.2 Lack of fine-grained coordination
爲了進一步支持有狀態應用，無服務框架需要提供一種方法來協調任務。例如如果任務 A 使用任務 B 的輸出，那麼即使 A 和 B 位於不同的節點上，也必須有辦法讓 A 知道它的輸入何時可用，很多保障數據一致性的協議也需要類似的協調。
現有的雲存儲服務都沒有通知功能，雖然雲服務提供商提供了獨立的通知服務，比如 SNS 和 SQS，但這些服務會顯著地增加延遲，有時會延遲數百毫秒，此外，當用於細粒度協調時，它們的成本可能很高。已經有人提出了一些系統，比如 Pocket，它們沒有這些缺點，但是還沒有被雲提供商採用。
同樣的，應用程序要麼管理一個基於 VM 的系統通知（例如在 ElastiCache 或 SAND 中），或者實現自己的通知機制（例如在 ExCamera 中的那樣），使得雲函數能夠通過長期運行的 VM 來彼此溝通。這一限制還表明，無服務計算的新形式可能值得研究，例如命名函數實例並允許直接尋址訪問它們的內部狀態。
3.3 Poor performance for standard communication patterns
在分佈式系統中，廣播、聚合和 shuffle 是一些最常見的通信原語，這些操作經常被機器學習訓練和大數據分析所使用，圖2顯示了基於 VM 和基於函數的通信模式。
使用基於 VM 的解決方案，在同一個實例上運行的任務都可以共享數據廣播的副本，或者在將部分結果發送到其他實例之前執行本地聚合，因此廣播和聚合操作的通信複雜度爲 O(N)，其中 N 是系統中 VM 實例的數量。然而，對於雲函數，這種複雜度爲 O(NK)，其中 K 是每個 VM 中的函數數量。這種操作在 shuffle 操作中更爲顯著，在基於 VM 的解決方案中，所有本地任務都可以組合它們的數據，這樣兩個 VM 實例之間就只有一條消息，假設發送方和接收方的數量相同，則產生 NN 條消息，對於雲函數來說，我們需要發送 (NK)(N*K) 條消息，由於現有函數擁有的核數量比 VM 少的多，K 通常在 10 到 100 之間。因爲應用程序無法控制雲函數的位置，因此無服務計算應用可能需要發送比同等的基於 VM 的方法多 2-4 個數量級的數據。
3.4 Predictable Performance
儘管雲函數的啓動延遲比傳統的基於 VM 實例要低得多，但是對於某些應用來說，啓動新實例時的延遲可能很高。影響冷啓動延遲的因素有三個：1）啓動雲函數所需要的時間；2）初始化函數的軟件環境所需要的時間，如加載 Python 庫；3）用戶代碼中特定應用程序的初始化。後兩個需要的時間會更高一些，雖然啓動一個雲函數可能需要不到1秒，但加載所有應用程序庫可能需要幾十秒。
性能可預測性的另一個障礙是硬件資源的可變性，這是由於雲提供商選擇底層服務器的靈活性，在我們的實驗中，我們有時會獲得來自於不同硬件的 CPU 資源，這種不確定性暴露了雲提供商希望最大化資源利用率和性能可預測之間的權衡。
4 What Serverless Computing Should Become
既然我們已經解釋了當下的無服務計算及其侷限性，讓我們展望未來，瞭解如何將其優勢應用到更多的應用中。研究人員已經開始着手解決上面提到的問題，並探索如何改進無服務平臺和運行在其之上的負載性能。在伯克利的一些同事和我們的一些工作強調了分佈式系統、機器學習、編程模型的在無服務計算中的一些機遇和挑戰。在這裏，我們將更加廣泛地討論如何增加能夠一些應用和硬件類型，使得無服務計算更好的運行，並在五個領域中確定研究所遇到的挑戰：抽象、系統、網絡、安全和體系結構。
4.1 Abstraction challenges
資源需求：使用當下的無服務產品時，開發人員需要指定雲函數需要的內存大小和執行時間限制，但是不需要指定其他資源。這些抽象阻礙了那些希望在一些指定資源（如 CPU、GPU 或其他類型的加速器）方面有更多控制權的人。一個方法是讓開發者自己去明確指定這些資源需求，但是這將使雲提供商更難通過統計多路複用的方式來實現高利用率，因爲它對函數的調度施加了更多的約束，同時這也違背了無服務計算中讓開發者從管理雲應用中釋放出來的理念。
更好的替代方法是提高抽象級別，讓雲提供商推斷資源需求，而不是讓開發人員指定它們。爲此，雲提供商可以使用多種方法，從靜態代碼分析、分析以前的運行情況，到動態（重新）編譯，將代碼重新定向到其他體系結構。當解決方案必須與高級語言運行時使用的垃圾自動回收交互時，自動向函數提供適當大小的內存量就非常有吸引力，但也特別具有挑戰性。一些研究表明，這些語言運行時可以繼承進無服務平臺。
數據依賴：當下的雲函數平臺並沒有雲函數之間數據依賴的先驗知識，更不用說這些函數之間可能存在數據交換，這可能會導致次優的任務放置，從而導致低效的通信模式，如 MapReduce 和 numpywren 示例所示（參見第三章）。
解決這一挑戰的一種方法是，雲提供商公開一個 API 允許應用程序指定其計算圖，從而實現更好的放置決策並最小化通信開銷、提高性能。我們注意到，許多通用的分佈式框架（如 MapReduce、Apache Spark 和 Apache Beam／CLoud Dataflow）、並行 SQL 引擎（例如 BigQuery、Azure Cosmos DB）以及編排框架（例如 Apache Airflow）已經在內部生成了這樣的計算圖。原則上可以修改這些系統，使其運行在雲函數上，並將其計算圖公開給雲提供商。AWS Step Functions 通過提供狀態機語言和 API 在往這個方向前進。
4.2 System challenges
High-performance, affordable, transparently provisioned storage：正如第三章和表 5 中所討論的，我們可以看到兩種截然不同的無編址存儲器需求，Serverless Ephemeral Storage 和 Serverless Durable Storage。
臨時性存儲（Ephemeral Storage） 。在第三章中的前四個應用程序受到雲函數之間傳輸狀態的存儲系統的速度和延遲所限制，雖然它們的容量需求各不相同，但是都需要這樣的存儲來在應用生命週期中維護應用的狀態，應用完成後，可以丟棄狀態，這種臨時存儲也可以在其他應用中作爲緩存。
爲無服務應用提供臨時存儲的一種方法是使用優化的網絡棧構建分佈式內存服務，以保證微秒級的延遲。該系統可以使應用的函數在其生命週期內有效地存儲和交換，這樣的內存服務需要根據應用程序的需求自動擴展存儲容量和 IOPS。這樣的服務獨特之處在於，它不僅需要透明地分配內存，還需要透明地釋放內存，特別是當應用終止或失敗時，應該自動釋放分配給該應用的存儲。這種類似於操作系統在進程完成（或崩潰）時自動釋放進程分配的資源，此外，這種存儲必須提供跨應用的訪問保護和性能隔離。
RAMCloud 和 FaRM 表明，構建內存存儲系統是可能的，該系統可以提供微秒級延遲，並支持每個實例數十萬次 IOPS。它們通過優化整個軟件棧和利用 RDMA 來最小化延遲並實現這種性能，但是它們要求應用程序顯示地提供存儲，也不提供多個租戶之間的強隔離。最近的另一項工作 Pocket 旨在提供臨時存儲的抽象，但也缺乏自動擴縮容，需要應用預先分配存儲。
通過利用多路複用，這種臨時存儲可以比當今的 serverful 計算更節省內存，對於無服務計算，如果應用需要的內存少於分配的 VM 實例聚合的內存，那麼這些內存就會被浪費，相反對於共享內存服務，一個無服務應用程序沒有使用的內存都可以分配給另一個應用使用。事實上，多路複用甚至可以使單個應用程序受益：在 serverful 計算中，屬於同一應用程序的運行在另一個 VM 上的程序不能使用 VM 未使用的內存，而在共享內存服務的情況下它可以。當然，即使沒有無服務計算，如果雲函數不使用它的整個本地內存，也可能存在內部碎片，在某些情況下，將雲函數應用的狀態存儲在共享內存服務中可以減輕內存碎片化。
持久性存儲（Durable Storage） 。與其他應用程序一樣，我們的無服務數據庫應用受到存儲系統的延遲和 IOPS 的限制，但它也需要長期的數據存儲和文件系統的可變狀態語義。雖然很可能數據庫功能（包括 OLTP）將越來越多地座位 BaaS 提供，但是我們認爲這個應用代表了好幾種應用程序，這些應用程序需要比臨時存儲更長的保留時間和更強的持久性。要實現高性能的無服務持久性存儲，一種方法是利用基於 SSD 的分佈式存儲和分佈式內存緩存。最近的一個系統實現了這些目標，叫做 Anna key-value 數據庫，它通過組合多個現有的雲存儲產品實現了成本效率和高性能，這種設計的一個關鍵挑戰是在存在大量長尾訪問分佈的情況下實現低長尾延遲，因爲內存緩存容量可能比 SSD 容量低得多。使用這種微秒級訪問延遲的存儲技術，正在成爲解決這一挑戰的辦法。
與無服務臨時存儲類似，這種服務應該透明的提供並應確保應用程序和租戶之間的隔離，以確保安全性和可預測的性能。然而，無服務臨時性存儲當應用終止時將回收資源，無服務持久性存儲只能顯示地釋放資源（例如 “delete” 或 “remove” 命令），就像在傳統的存儲系統中，此外，它必須確保持久性，以便任何公認的寫操作都能保證容錯。
最小化啓動時間 。啓動時間分爲三個部分：（1）調度並啓動資源來運行雲函數；（2）下載應用軟件的運行時環境來運行函數代碼（例如操作系統、庫）；（3）執行特定於應用程序的啓動任務，如加載和初始化數據結構和庫。由於創建一個獨立的執行環境以及配置客戶的 VPC 和 IAM 策略，資源調度和初始化可能會導致嚴重的延遲和開銷。雲提供商最近都致力於通過開發新的輕量級隔離機制來減少啓動時間。
減少（2）的一種方法是利用 unikernels，Unikernels 通過兩種方式消除了傳統操作系統帶來的開銷。首先，不像傳統操作系統那樣動態監測硬件、應用配置和分配數據結構，Unikernels 通過爲運行的硬件預先配置和靜態分配數據結構來壓縮這些開銷；其次，Unikernels 只包含應用程序嚴格要求的驅動程序和系統庫，這比傳統操作系統佔用的內存要少得多。值得注意的是，由於 Unikernels 是爲特定的應用程序定製的，所以當運行多個標準化內核的實例時，它們無法實現一些可能的效率，例如在同一個 VM 上的不同雲函數之間共享內核代碼頁，或者通過提前緩存減少啓動時間。減少（2）的另一種辦法是動態地、增量地加載應用程序調用的庫，例如通過 Azure 函數中使用的共享文件系統啓用庫。
特定應用程序的初始化（3）是程序員的責任，但是雲提供商可以在其 API 中包含一個準備就緒信號，以避免在開始處理之前就將負載發送給函數實例，更廣泛地說，雲提供商可以在函數真正被調用前的一小段時間裏啓動任務。這對於與客戶無關的任務（例如使用流行的操作系統和一組庫啓動 VM）很有效，因爲此類實例的 “warm pool” 可以在租戶之間共享。
4.3 Networking challenges
如第三章和圖 2 所示，雲函數會給流行的通信原語（如廣播、聚合和 shuffle）帶來很大的開銷，假設我們可以將 K 個雲函數打包到一個 VM 實例上，一個雲函數版本將發送 K 倍於實例版本的信息，並且在 shuffle 時發送 K*K 多的信息。
有以下幾種方法可以應對這一挑戰：
爲雲函數提供更多的 CPU 核。類似於 VM 實例，多個任務可以在通過網絡發送數據之前或接收數據之後在這些核之間組合和共享數據；
允許開發人員顯示地將雲函數放在同一個 VM 實例上。提供應用程序可以直接使用的分佈式通信原語，以便雲提供商可以將雲函數分配給同一 VM 實例；
讓應用程序提供一個計算圖，使雲提供商能夠定位雲函數，以最小化通信開銷（參見上面的 “抽象挑戰”）
需要注意的是，前兩個建議可能會降低雲提供商放置雲函數的靈活性，從而降低數據中心的利用率，可以說，它們還違背了無服務計算的精神，迫使開發人員考慮系統管理。
4.4 Security challenges
無服務計算重新劃分了安全職責，將其中許多職責從雲用戶轉移到雲提供商，而沒有從根本上改變它們。然而，無服務計算還必須解決應用分解後多租戶資源共享所固有的風險。
調度隨機化和物理隔離。物理混合部署是硬件級別側通道或 Rowhammer 攻擊的核心，作爲這類攻擊的第一步，攻擊者需要確認與受害者在同一物理主機上是混部的，而不是隨意攻擊陌生人。雲函數的短暫性可能會限制攻擊者識別並行運行的目標的能力，一個隨機的 adversary-aware 調度算法可能會降低攻擊者和受害者混部在一起的風險，使得這種攻擊更佳困難。然而，故意阻止物理混部可能與作業放置來優化啓動時間、資源利用率或通信相沖突。
細粒度安全環境。雲函數需要細粒度的配置，包括獲得私鑰、存儲對象，甚至是本地的臨時資源，這需要從現有的 serverful 應用轉換安全策略，併爲在雲函數中動態使用提供易表達的安全接口。例如，一個雲函數可能必須將安全特權委託給另一個雲函數或雲服務，使用基於加密保護的訪問控制機制非常適合這種分佈式安全模型。最近的工作建議在多方設置中使用信息流控制實現跨函數的訪問控制，如果爲雲函數動態地創建短期密鑰和證書，則爲安全原語提供分佈式管理的挑戰將會加劇。
在系統級，用戶需要對每個函數進行更細粒度的安全隔離，至少可以選擇這樣做。提供函數級別的沙箱所面臨的挑戰在於，在不緩存執行環境的情況下保持很短的啓動時間，而不會在重複函數調用之間共享狀態。一種可能是給實例建立本地快照，這樣每個函數都可以從乾淨的狀態開始。另外，輕量級虛擬化技術開始被無服務提供商採用：庫操作系統（包括 gVisor）在用戶空間的 “shim layer” 中實現系統 API，而 unikernel 和 microVMS（包括 AWS Firecracker）簡化了客戶內核並幫助減少攻擊。與以秒爲單位測量的 VM 啓動時間相比，這些隔離技術將啓動時間減少到幾十毫秒。這些解決方案是否能在安全性方面與 VM 對等還有待證明，我們希望尋找具有低啓動開銷的隔離機制，這將是當前研究和開發的一個活躍領域。從積極的角度來看，在無服務計算中，提供管理和短生命週期的實例可以使得漏斗更快地得到修補。
對於那些想要保護自己不受鄰居攻擊的用戶，一種解決方案是要求物理隔離。最近的硬件攻擊（例如 Spectre 和 Meltdown）也是保留整個 CPU 核甚至整個物理機來吸引用戶。雲提供商可以爲用戶提供一個高級選項，讓他們在專用於自己的物理機上啓動函數。
Oblivious serverless computing。雲函數可以通過通信泄露其訪問模式和時間信息。對於 serverful 應用，通常以批處理方式檢索數據，並在本地緩存，相反的是，因爲雲函數都很短暫並且廣泛地分佈在整個雲上，網絡傳輸模式可以向網絡攻擊者泄露更多敏感的信息，即使負載是端到端加密的。將無服務應用分解爲許多小函數的趨勢加劇了這種安全性暴露，雖然主要的安全問題來自外部攻擊者，但是通過採用 oblivious 算法可以保護網絡模式不受員工的攻擊，不幸的是，這些方法的開銷往往很高。
4.5 Computer architecture challenges
硬件異構性、定價、易於管理。主導雲計算的 x86 位處理器的性能幾乎沒有提高，在 2017年，單個項目的性能提升僅爲 3%，假設按照這種趨勢繼續下去，在 20 年內性能不會翻倍。同樣，每個芯片的 DRAM 容量正在接近極限，現在有 16 Gbit 的 DRAM 在出售，但是要製造一個 32 個 Gbit 的 DRAM 芯片幾乎是不可能的。這種緩慢變化帶來的一線希望是，隨着舊電腦的磨損，供應商可以更換它們，而對當前的無服務市場幾乎沒有影響。
通用微處理器的性能問題不會降低對更快的計算的需求。有兩條路可以走，對於用 JavaScript 或 Python 等高級腳本語言編寫的函數，軟硬件協同設計可以使特定於語言的定製處理器的運行速度提高 1-3 個數量級；另一條路是特定領域的體系結構（DSA）。DSA 針對特定的問題領域進行了定製，併爲該領域提供了顯著的性能和效率提高，但是對於該領域之外的應用性能很差。GPU 長期以來一直被用來加速圖像，我們開始看到 DSAs 用於機器學習，比如 TPU。TPU 的性能可以比 CPU 高出 30 倍，這些示例只是衆多示例中的第一個，因爲使用 DSA 增強用於不同領域的通用處理器將成爲規範。
正如在 4.1 節中提到的，我們看到了兩種無服務計算方法來支持即將到來的硬件異構性：
- Serverless 可以包含多種實例類型，每個計費單元的價格取決於使用的硬件；
- 雲提供商可以自動選擇基於語言的加速器和 DSAs。這種自動化可以隱式地基於雲函數中使用的軟件庫和語言來完成，比如用於 CUDA 代碼的 GPU 硬件和用於 TensorFlow 代碼的 TPU 硬件，或者雲提供商可以監視雲函數的性能，並在下次運行時將它們遷移到最合適的硬件上。
對於 x86 的 SIMD 指令，無服務計算正以一種較小的方式面臨異構性。AMD 和英特爾通過增加每個時鐘週期執行的操作數量和添加新的指令，改進了部分 x86 指令集。對於使用 SIMD 指令的程序，在最新的 Intel Skylake 微處理器上運行帶有 512 位寬指令的程序要比在老的 Intel Broadwell 微處理器上運行帶有 128 位寬的 SIMD 指令程序快得多。今天，這兩個微處理器在 AWS Lambda 中價格相同，但是對於無服務計算用戶來說，目前沒有辦法表明他們想要更快的 SIMD 硬件，在我們看來，編譯器應該建議哪種硬件是最好的。
隨着加速器在雲中越來越流行，無服務計算的雲提供商不能在忽視異構帶來的困境，特別是在可能的補救措施存在的情況下。
5 Fallacies and Pitfalls
本章使用 Hennessy 和 Patterson 的 Fallacy 和 Pitfall 風格。
Fallacy。因爲一個 AWS Lambda 雲函數實例與內存大小相同的 on-demand AWS t3.nano 實例每分鐘開銷要多 7.5 倍，無服務計算比 serverful 雲計算價格更高。
無服務計算的優點在於價格中包含了實際使用的資源外還包括了整個系統管理，包括可用性冗餘、監控、日誌記錄和彈性伸縮。雲提供商的數據顯示，當客戶將應用遷移到無服務環境中時，可以節省 4-10 倍的成本，並且其在相同功能下遠不止一個 t3.nano 實例。對於一個單點故障，其 credit 系統會將其限制在每個小時最多使用 6 分鐘 CPU，所以它可以在負載高峯期拒絕服務，而 serverless 可以很容易應用這個負載高峯。Serverless 可以更細粒度地進行計費，包括自動擴縮容，因此在計算量上可能更加高效，因爲雲函數在沒有被調用時是不計費的，所以 serverless 可能更加便宜。
Pitfall。無服務器計算可能存在成本不可預測的情況。
對於一些用戶來說，無服務計算採用即付即用的計費模型的一個缺點是成本不可預測。這與許多組織管理預算的方式不太一致，當公司想要知道下一年無服務計算的成本預算是多少，並來批准預算時就不太好制定預算。這種需求是合理的，雲提供商可能會通過提供基於 bucket 的定價方式來緩解這個問題，類似於電話公司爲特定使用量提供固定費率計費方式一樣。我們還相信，隨着越來越多的組織使用無服務計算，他們將能夠基於歷史來預測他們的成本，就像當今公共事業服務（如電力）所使用的辦法。
Fallacy。由於無服務計算編程是用高級語言編寫的（例如 Python），所以很容易在無服務計算提供商之間移植應用。
在不同的無服務計算提供商之間，不僅僅是函數的調用語義和打包方式不同，許多無服務應用也依賴於其生態系統的專有 BaaS 服務（例如對象存儲、鍵值數據庫、身份驗證、日誌監控等），缺乏統一標準化。爲了實現可移植，無服務計算的用戶將不得不提出並接受某種標準 API，例如 POSIX 試圖爲操作系統提供這種 API。Google 的 Knative 項目就是爲了解決這個問題，它爲應用開發者提供了一組統一的原語，以便在部署環境中使用。
Pitfall。與使用 serverful 計算相比，使用無服務計算時，供應商 lock-in 可能會更強。
這個陷阱是前一個謬論的結果，如果一直很困難，那麼供應商 lock-in 是可能的，一些框架承諾通過跨雲支持來減輕這種 lock-in。
Fallacy。雲函數不能處理非常低延遲的應用程序，這需要預測其性能。
Serverful 實例能夠很好地處理這種低延遲應用的原因是，它們總是處於待命狀態，所以當它們接收到請求時，可以快速響應。我們注意到，如果一個雲函數的啓動性能對於給定的應用來說還不夠好，那麼可以使用類似的策略：通過定期執行雲函數來預熱雲函數，以確保在任何給定時間都有足夠的雲函數。
Pitfall。很少有所謂的“彈性”服務能夠滿足無服務計算的實際靈活性需求。
“彈性” 是當下很流行的一個術語，但是它被應用於那些伸縮性不如無服務計算服務的服務。我們對那些可以快速改變它們容量大小的服務很感興趣，並且用戶的干預度最小，在不使用時可以“縮容到0”。例如，儘管 AWS ElastiCache 名字中有彈性一詞，但它之允許實例化一個整數個 Redis 實例。其他“彈性”服務需要顯示的進行容量供應，有些服務需要花費許多時間來響應需求的變化，或者之擴展到有限的範圍。當用戶構建一個高彈性的應用，並且包含數據庫、搜索索引或者有有限彈性的 serverful 應用時，他們會失去很多無服務計算的優勢，如果沒有一個量化的、被廣泛接受的技術定義或度量（有助於比較或組合系統），“彈性” 將仍然是一個模糊的詞彙。
6 總結和預測
通過提供一個簡化的編程環境，無服務計算加強了雲的易用性，從而吸引更多的人。無服務計算由 FaaS 和 BaaS 服務組成，標誌着雲編程的成熟，它消除了 serverful 計算強加給應用開發人員的資源管理和優化的工作，這類似於四十多年前從彙編語言遷移到高級語言的轉變。
我們預測無服務計算的使用將會激增，我們還預測，將混合雲應用將隨着時間的推移而減少，儘管由於監管約束和數據治理規則，一些部署可能會持續。
雖然無服務計算已經取得了成功，但是我們明確了一些其可能遇到的挑戰，如果這些困難能得以解決，無服務計算將在更大的範圍內被廣泛使用。第一步是無服務計算的臨時存儲，它必須以合理的成本提供低延遲和高 IOPS，但不需要提供經濟的長期存儲。第二類應用程序將受益於無服務器的持久性存儲，新的非易失性內存技術可能對這種存儲系統有所幫助。低延遲的信令服務和對流行通信原語的支持將使得無服務計算受益匪淺。
未來無服務計算的兩個挑戰在於如何提高安全性和適應來自特殊用途處理器的成本性能改進，在這兩種情況下，無服務計算的特性可能有助於解決這些挑戰。物理上的共存是側道攻擊的必要條件，但是在無服務計算中很難確定函數的位置，而且很容易地進行位置隨機化。雲函數是使用高級語言進行編程的，例如 JavaScript、Python 或 TensorFlow，這些高級語言提升了編程的抽象層級並且更加容易進行創新，進而使得底層的硬件可以帶來開銷和性能的提升。
在 《The Berkeley View on Cloud Computing》 一文中作者預測，2009 雲計算所面臨的挑戰將得到解決，並將蓬勃發展。雲業務現在正以每年 50% 的速度增長，並且實時證明，雲提供商的利潤非常豐厚。
最後，我們對未來十年的無服務計算做出如下預測：
- 我們希望能創建新的 BaaS 存儲服務，在無服務計算上能擴展更多的應用類型，這樣的存儲將與本地塊存儲的性能相匹配，並且具有臨時性和持久性存儲的特性，我們將看到計算機硬件的異構性要比傳統的 x86 微處理器強得多。
- 我們希望無服務計算可以比 serverful 計算更容易安全地編程，這得益於高級編程的抽象和雲函數的細粒度隔離。
- 我們沒有看到無服務計算的成本應該高於 serverful 計算的根本原因，因此我們預測計費模型將會繼續發展，這樣幾乎任何應用程序可以運行在任何規模上，並且使得無服務計算的成本都不會增加，甚至可能更少。
- 未來的 Serverful 計算將會爲 BaaS 提供便利，事實證明，例如像 OLTP 數據庫或通信原語（如隊列）這類應用，很難在無服務計算之上編寫，未來可能會作爲雲提供商所提供服務的一部分。
- 雖然 serverful 計算不會消失，但隨着無服務計算解決了當前限制，這部分雲計算的相對重要性將會下降。
- 無服務計算將成爲雲時代的默認計算範式，在很大程度上取代 serverful 計算，從而結束客戶機-服務器時代。
歡迎大家關注我的知乎專欄，進擊的雲計算。