當前Serverless計算平臺的局限性
Serverless Cloud Functions已經被成功應用于很多不同的場景，但仍然有許多場景沒有使用serverless計算，為了探究是什么阻礙了serverless計算應用于更加廣泛的場景，我們選擇了幾個感興趣的應用，以及一些其他人的研究樣本，嘗試把他們改造成serverless的形式來發現阻礙改造的難點。
在這一部分中，我們挑選了5個用于研究的項目，他們原本都是基于傳統serverful云計算的應用，而我們盡可能只使用cloud functions來實現它們的serverless版本，除了最后一個例子 —— Serverless SQLite，FaaS在這方面的支持太過薄弱，因此我們認為數據庫和其他較重規模的有狀態服務將仍然以BaaS的形式存在。
有趣的是，盡管這些應用是我們隨意挑選的，本身并沒有太多的相似點，但在它們身上暴露出的serverless計算的弱點確實相同的，下面就讓我們來看看這些例子。
ExCamera：實時視頻編碼
ExCamera 是一個給用戶提供實時視頻編碼的服務，用于幫助他們把視頻上傳到Youtbue這樣的網站上。取決于不同的視頻文件大小，編碼方案可能需要花費數十分鐘甚至數小時的時間。為了能夠實現實時的視頻編碼，ExCamera把編碼過程中比較慢的部分并行化，比較快的部分則繼續使用串行化。ExCamera對外暴露了視頻編碼器和解碼器的接口，使你可以通過調用函數的方式來完成相關的任務。
MapReduce
大數據分析框架，如MapReduce, Hadoop 和 Spark，在傳統方式下都是部署在可控制集群上的。目前一些純Map相關的任務已經可以運行在serverless計算環境中了，下一步需要支持的就是完整的MapReduce任務。推動這一改進的潛在動力是serverless計算帶來的靈活性，它能夠有效地處理一些數據集大小變化非常明顯的任務，增加資源的利用率。
Numpywren：線性代數
大規模的線性代數計算過去基本是被部署在由高速網絡連接的高性能集群，或者超算上。基于這樣的歷史背景，serverless計算看起來并不能夠勝任這一工作。不過目前有兩個讓serverless計算對線性代數運算領域產生意義的因素：一是管理集群對于非計算機專業的研究人員而言是一件非常吃力的事情，二是整個計算過程中的并行數量可能變化的非常劇烈，使用固定容量的集群有可能使得計算過程變得非常緩慢（機器數量太少），或者使得整個集群的資源利用率非常低（機器數量太多）。
Cirrus：機器學習訓練
機器學習研究人員過去使用VM集群來處理機器學習相關的工作流，比如預處理、模型訓練和超參數調整。這種方式有一個挑戰，那就是整個處理過程的不同步驟對資源數量的要求存在顯著的差別。和線性代數運算一樣，使用固定數量的集群會造成計算的緩慢或者資源的浪費。利用serverless計算的彈性縮擴容能力可以很好的解決資源利用率的問題，同時也可以把科研人員從管理集群的繁瑣任務中釋放出來。
Serverless SQLite：數據庫
如今市面上已經存在許多不同的具有自動縮擴容能力的數據庫服務，但serverless計算在這方面卻十分乏力。為了更好的理解serverless計算在這方面存在的限制，就需要先搞明白數據庫的工作負載為什么那么難以實現。對于這種情況，我們考慮了對于第三方而言，是否可能直接使用cloud functions這種serverless計算的通用模塊來構建一個serverless的數據庫。一個可能會受到抨擊的方案是直接在cloud functions里運行傳統的事務型數據庫，比如PostgreSQL，Oracle或者MySQL，這種方案有非常多的挑戰：首先，serverless計算沒有內建的持久化儲存，所以我們需要利用遠程的持久化儲存，這必定會導致較大的延遲；其次，數據庫一般使用基于連接的協議，而現有的cloud functions一般運行在網絡地址轉換器的上層，無法向客戶端提供穩定的長連接；最后，由于大多數的高性能數據庫都依賴于共享內存，物理隔離的cloud functions則無法實現這一點，而那些無需共享內存的數據庫也要求所有的節點始終保持在線并且可以根據地址直連。上述的問題在severless計算中都難以得到解決，因此我們認為數據庫應該仍以BaaS的形態存在。
serverless計算對上面列舉的這些應用而言有一個共同的優勢，那就是自動縮擴容，這樣可以應對應用急劇變化的資源需求。下面的表格總結了上述五個應用的特性、挑戰以及可能的變通方法，我們將根據它來論述serverless計算目前面臨的幾個局限。