当前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计算目前面临的几个局限。