闲谈 Serverless，价值和未来

什么是 serverless

笔者接触 serverless 的时间仅两年时间，对于此概念的起源并没有过多深究，所以不一定准确，仅作猜测和交流。在我了解的范围内，aws 的 lambda 可能是最早的 serverless 产品。从其产品形态猜测，其产品推出的最初原动力可能是“提供一个 可编程脚本来对云服务进行一些个性化处理“。

之所以如此猜测，原因有以下：

• lambda 与 aws 云服务结合较为密切，并且相关 sdk 和接口齐全，平台依赖非常强。

• lambda 对本地调试以及用户自定义开发并不十分友好。

笔者曾从 0 到 1 设计并搭建函数计算平台，假如从一开始就考虑到本地开发调试、以及适配更广泛的应用结构和可迁移性。它的产品形态必然与现在的 lambda 有较大差异。所以我认为 lambda 设计之初，可能就是为了 aws 上的云服务，并不是为通用开发场景设计。

随着 lambda 函数用量的逐渐增多，需求逐渐外展，被用于更多方面，它的概念逐渐被人所知，也越发复杂。

serverless 价值

任何概念只有解决实际问题才有价值。假如现有的 serverless 产品，离开公有云，不与公有云进行耦合，面向通用开发场景。那么其价值是什么？在我看来无非有以下两个价值：

（1）字面价值：只写代码，不管部署和服务器运维。

这个是一个美好的愿望，距离完全实现还有距离。即便在公有云上，按照其给定的框架开发的产品，也必须要配置扩缩容策略、内存等一堆策略。更别说自定义框架要要配启动命令等。私有云还有一堆的规范要遵守，会更麻烦。但是有剩于无，与容器部署相比还是少了一些配置的。随着这项技术的发展，想必会距离此目标越来越近。

（2）真实价值：高性能自动扩缩容。

对于企业以及企业开发人员来说，其实这个才是最具价值的点。随着大量企业上云，资源申请以及部署开启云模式自服务化，企业的资源利用率是在下降的。传统虚拟机模式下，很多应用可能公用虚拟机，运维人员根据利用率将业务程序部署到虚拟机上，直到其利用率较高再扩容或者到其他虚拟机。 但是在云模式下，虚拟机等资源由开发人员自行申请。这就带来了一些问题：

• 开发人员既没有意识，也没有动力去节省资源。与其自己规划使用，实时监测，不如申请不同的资源方便。

• 如果资源紧张，申请资源经常失败，那么会造成开发人员提前申请，尽管没有使用，先申请着放在那里，以备不时之需。

• 业务有波峰波谷，那必然是按照波峰的流量来申请。比如一些批处理任务，可能一天、一周甚至一月执行一次，但是它仍然会长期占有资源。

部分企业可能通过实时监测然后发通知去整改，甚至通过计量计费去分摊成本并与部门业绩挂钩等方式倒逼开发人员节省资源。但是笔者认为，这些都治标不治本。以 redis 为例，也许部分工程用量不高，但是确实有需要，那么这种该怎么办？如果按最小实例申请，流量洪峰来了撑不住又怎么办？以行政或绩效手段去倒逼开发人员既不科学合理，也不人性。

针对此情景，笔者认为以技术的方式去解决，将资源配额的申请转交由平台自动处理才是可行之道。

serverless 的未来发展趋势

价值决定趋势。从前章 serverlss 的价值出发可以推测 serverless 的趋势有以下两个方面：

（1）纵向发展

在代码开发方面，将会支撑更多场景，并且逐渐去平台化。

（2）横向发展

向基础设施、中间件等场景蔓延，重构基础设施和中间件的形态，做到按需使用、自动分配。比如数据库、redis、kafka、虚拟机等。

以 redis 为例，也许 serverless 化的 redis 在申请的时候没有配额选项。只有认证信息、链接地址、和前缀等。至于内部如何调度、如何扩容由 redis 平台自动处理。