Serverless計算應該是什么樣的
現在讓我們把目光投向未來，分析如何將severless的優勢帶給更多的應用。研究者們已經開始解決我們之前提到的諸多問題，并且嘗試去探索如何進一步改進serverless平臺和運行在它之上的工作負載。下面我們將給出困擾serverless計算應用于更廣泛的硬件和軟件范圍的五大挑戰：抽象、系統、網絡、安全以及架構。
4.1 抽象挑戰
資源需求： 今天的serverless平臺給開發者提供的cloud functions只包含內存大小和執行時間的限制，但是其他的資源是無法調控的。這對于那些想要控制更多指定資源（如CPU數，GPU數或加速器類型）的開發者來說是一個很大的阻礙。如果允許開發者明確地指定各種資源的需求，又會導致云供應商無法很好的實現資源的高利用率，因為這會給函數的調度增加許多限制。而且這也違背了serverlss本身降低開發人員對服務器關注度的初衷。
一個更好的可選方案是提高抽象的層級，讓云供應商來推斷函數服務的資源需求，而不是由開發者手動去聲明。要實現這一點，云供應商可以使用很多手段，比如靜態代碼分析，歷史運行記錄分析，或者是動態地調整代碼運行的架構。
給正在運行的程序自動分配適量的內存是一個極具吸引力的終極目標，然而要實現它卻充滿了挑戰性，因為必須和高級語言運行時環境的GC系統進行交互。有些研究表明這些語言的運行時環境(runtime)可以完全下沉到serverless平臺中，使二者成為一個整體。
數據依賴： 如今的云平臺還無法感知不同cloud functions之間的數據依賴，更不用說它們之間交互的數據量了。這種缺陷可能會通信模式的低效率，就像我們在第3部分中提到的那樣。
一種解決方案是由云供應商來提供允許應用聲明它們計算圖譜 (computation graph) 的API，來推斷能夠使通信成本最小化的放置方案。我們注意到許多通用的分布式框架（如MapReduce，Apache Spark，Apache Beam 和 Cloud Dataflow）、并行SQL引擎（如BigQUery，Azure CosmosDB）和一些調度框架（如Apache Airflow）早就在它們內部應用了計算圖譜。原則上來說，這些系統經過改造后都可以運行在cloud functions上，并且向云供應商暴露它們的計算圖譜。AWS Step Functions在此領域已經有了一定的進展，它通過提供一種機器狀態語言和API的方式來解決此類問題。
4.2 系統挑戰
高性能，可負擔，可透明配置的儲存： 我們在第3部分中討論過兩類不同的無地址儲存訴求：Serverless短期儲存和Serverles持久儲存。
短期儲存：
在第3部分中提到的前四個應用都受到了儲存系統的速度和延遲限制，盡管它們所需要的能力各有不同，但都需要一種在整個應用聲明周期中維持應用狀態的儲存。這樣的短期儲存在其他應用中可能以緩存的方式存在，一旦應用運行完畢，這些狀態就可以被銷毀。
一種給serverlss應用提供短期儲存能力的方案是構建一個分布式的內存緩存服務，我們需要優化網絡堆棧來保證毫秒級別的延遲，這樣系統就可以允許應用函數在其生命周期內更有效的儲存和交換狀態。對于這個內存緩存服務，需要實現自動的縮擴容，并提供滿足應用需求的IO吞吐能力。一種獨特的觀點是：通過它應用不僅可以透明地分配內存，也可以透明地釋放內存。特別地，當某個應用終止或異常退出時，為其分配的短期儲存應該被立刻釋放。這種管理手段和操作系統為進程自動分配和釋放內存的功能有點類似。進一步地，這樣的儲存還必須為應用提供訪問權限保護，并且對跨應用的數據進行隔離。
RAMCloud 和 FaRM 已經向我們展示了構建具有毫米級延遲和萬級IOPS能力的內存緩存系統的可能性，他們通過對整個系統進行精細優化和RDMA技術的使用最大化的降低了延遲。不過仍然需要應用提供儲存使用的聲明，而且也未能保證不同租戶之間的儲存強隔離。另一個產品Pocket目前正發力解決短期儲存的抽象問題，但也還是不能夠提供自動縮擴容的特性。
通過利用統計復用 (statistical multiplexing) 技術，serverless計算的短期儲存可以改造的比現在更加有效率。在serverful計算中，如果一個應用使用的緩存空間只是為它分配的VM實例上內存的一小部分，其余的內存空間就都被浪費掉了。相對的，在serverless計算中，如果我們使用共享的內存服務 (shared in-memory service)，那么這些未被利用的內存就可以被其他的應用所使用。實際上，即便只有一個應用在運行，它也可以從統計復用技術中獲利：在serverful計算中，一個VM上未被利用的內存是不能夠被運行在其他VM上的程序所使用的，但如果使用共享的內存服務，情況就不一樣了。當然，在serverlss計算中，如果cloud functions不能很好地利用它們的本地內存，也會產生許多的內存碎片，在某些場景下，把cloud functions的應用狀態存放在共享內的存服務中可以緩解內存碎片的問題。