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