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的应用状态存放在共享内的存服务中可以缓解内存碎片的问题。