从函数计算到 Serverless 架构

前言

随着 Serverless 架构的不断发展，各云厂商和开源社区都已经在布局 Serverless 领域，一方面表现在云厂商推出传统服务/业务的 Serverless 化版本，或者 Serverless 计算平台，另一方面表现在开源社区中 Serverless 相关项目逐渐丰富起来，无论是平台类还是工具类的开源项目，再或者是框架类的开源项目，都如雨后春笋般快速成长。

任何技术，在这样繁荣发展背后，都会快速升级和迭代，Serverless 架构也不例外，从阿里云的 FaaS 产品发展过程中，不难看出 Serverless 架构在提效和降本的道路上不断的场景化，特色化；在产品形态上也不断的趋于完整化，统一化，虽然距离“大道至简”还有一定的距离，但是也只是时间的问题了。

从思想到产品升级

Serverless 架构在不断发展，无论是产品形态还是技术架构都可以用日新月异来描述。

Serverless 精神的更迭

最初，Serverless 架构指的是 FaaS 与 BaaS 的结合，认为开发者可以不用花费更多的精力在服务器等底层资源上，而是可以将精力放在更具价值的业务逻辑之上。这也是文章《Serverless Architectures》中所强调的观点。

但随着时间发展，大家发现，对于 Serverless 架构这样的描述过于单薄，没有凸显出 Serverless 架构为业务带来的技术红利，也没能表现出 Serverless 所交付的心智。所以 UC 伯克利在《Cloud Programming Simplified: A Berkeley View on Serverless Computing》中对 Serverless 架构进一步的定义：对于被认为是 Serverless 架构的服务/产品还需要具备按量付费和弹性伸缩的特点，并认为， long-run 的运行模式并不符合 Serverless 精神。

云计算相关技术的发展，往往有一个特点：云厂商的驱动性非常强，因为云厂商往往会最先感知到普遍性的用户需求，并且有足够的数据支撑其做出合理的判断与创新。所以 Serverless 架构的创新很多时候也都是由厂商驱动的；在事件驱动与函数计算的发展下，厂商逐渐发现函数计算的模式“短时运行”没有办法满足更多用户的诉求，此时一种 long-run 模式的 Serverless 计算服务就逐渐的被孵化出来了，至此，Serverless 架构也从最初的单薄，逐渐完善，通过“自我革新”，完成了新一轮业务能力的自我丰富与产品功能的自我完善。

随着 long-run 模式逐渐被开发者们认可，传统 Serverless 架构的定义有点“格格不入”：既不能在模式上覆盖最新的 Serverless 产品纬度，也不能在形态上描述清 Serverless 的特性。此时 Serverless 架构定的义，就自然而然的得以升级，例如：

• Serverless 应该是 FaaS + BaaS + CaaS，

• Serverless 应该是 FaaS + BaaS + Others，

• Serverless 就是 Server+Less，即服务端免运维/低运维的形式就是真正意义上的 Serverless 架构。

至此，Serverless 架构实现了此阶段下的产品形态升级与 Serverless 精神的更迭。

从函数到更 Serverless

通过阿里云官网，不难发现其 Serverless 产品形态还是相对完整的：

• 计算平台：从函数计算到容器镜像再到微服务形态；

• 基础产品/服务：存储产品、数据库等产品的 Serverless 形态；

Serverless 架构的热度不断增加，各产品也需要借着热度进一步突破和创新，所以 Serverless 这个词“被乱用”再所难免；每个团队都有自己的特色，基于 Serverless 架构完善和更迭自身能力，也是产品发展的必经之路，就像数据库发展到云数据库，再发展到云原生数据库，再发展到 Serverless 数据库一样；

所以，Serverless 架构需要一个“粘合剂”，将各种 Serverless 产品进行进一步的链接，使其不是“混杂在诸多产品中的某些产品”，而是“可以联合起来解决某个问题的具体功能”，换句话来说将不同的产品联合到一起，以应用的维度为开发者