接受还是观望？

云计算未来一定会成为整个社会和商业的基础设施，届时使用云计算就应该像现在我们使用水电煤一样简单，不需要了解水从哪里来、怎么过滤、怎么铺设管道等一系列问题，只需要打开水龙头接一杯水而已。而 Serverless 的概念正好可以帮助云计算朝这个方向往前走一步，它提倡的是人们不需要关心应用逻辑以外的服务相关的事情，包括管理、配置、运维等，用多少就付多少。

从这个角度来看， Serverless 是真正让云计算变成社会商业基础设施的一个实现路径，也更接近现在业内提倡的云原生的方式，因此人们在使用云计算的过程中自然就应该按照 Serverless 的方式来使用。

国外的开发者在 Serverless 领域的心智明显比国内开发者建立的更好。因为国外很多公司一开始就是基于 Lambda 生态来创业的，而国内一些大企业已经陆续开始使用 Serverless 的工具和产品，还有很大一部分企业处于观望状态。

一个新产品的出现也是要有一个适应期的，所以在 Serverless 这样一系列产品出现之后，用户对于是否使用、是否迁移、如何迁移是有很多顾虑的。经常会有企业咨询关于函数计算的安全性如何保证，函数计算的稳定性如何保证，以及传统项目迁移到 Serverless 架构是否有比较大的改造成本和改造风险等。这些顾虑很正常，但是我相信，随着 Serverless 的发展， FaaS 定义的越发广泛，工具链建设的越发完整，这些问题都会逐渐被解决。理论上，技术能解决的问题，都不算问题。

没有规模，不要自建 Serverless

Serverless 带来的极致弹性体验、成本节约、开发效率提升等，都是非常具有吸引力的。传统业务在开发上线的过程中，需要团队合作，每个人开发一部分，合并代码，开发联调，然后进行资源评估，测试环境搭建、线上环境搭建、测试上线、运维。但是在 Serverless 时代下，开发者只需要开发自己那部分功能/函数，然后部署到测试环境、线上环境即可，后期很大一部分运维工作都不用考虑和担心。

可以毫不夸张的说，如果企业自己通过云主机搭建的数据库服务，一般情况下可用性不如云厂商提供的数据库服务，此外，API 网关、数据存储服务等也是云厂商提供的产品性能更好，也更安全可靠。

小企业最好不要自己去建设 Serverless。因为 Serverless 的核心要素是按量使用，这就意味着如果今天的量很小，你就用很少的资源；如果今天的量很大，就需要调动更多的资源。“双十一”的时候，流量都是亿的量级，如果你的企业内部没有按亿级做单位的这种流量的机器资源，你怎么去调度这些资源给他人使用呢？没办法实现按量调度，就别提 Serverless 了。那些不具备资源规模化的企业不建议去自建 Serverless 能力，但是可以通过使用公有云的产品来实践 Serverless。

当下，各大厂商都看准了 Serverless 是未来，就算它不是云计算的终态，也是通往终态的一个途径，一方面是因为 Serverless 可以解决很多实际问题，更“像”或者说更“贴近”真正的云计算；另一方面，大家都不想在云计算发展的浪潮中掉队。所以， Serverless 成了必争之地。

关于 Serverless 能力的竞争主要有三部分：

一是性能，包括安全、稳定、弹性等在内，性能这部分如果做不好，我觉得不用说做不做 Serverless ，就算云计算也别做了，因为性能是 Serverless 的核心能力，一切都建立在安全、稳定、性能之上。

二是功能，想要把 Serverless 做好，功能是不可缺少的。因为 Serverless 不仅仅是 FaaS ，就算是 FaaS 也不仅仅是在线运行，还包括很多东西，如 BaaS 、触发器、日志、监控、告警等。只有在功能上满足开发者的诉求，开发者才有可能愿意使用。

最后是体验， Serverless 的体验太重要了，体验包括方方面面，如功能的易用性、稳定性、安全性、产品的灵活性、工具链的完整性等。除了前面说的三点，我觉得社区、生态、开放等，也非常重要。

阿里云作为国内第一批推出 Serverless 平台的公有云厂商，其 FaaS 平台产品被称为函数计算。从事件触发、支持语言以及用户体验等方面考量，函数计算有很多数据值得关注：

  • 事件触发：阿里云函数计算可以被阿里云上的服务事件触发，例如阿里云对象存储（OSS）、日志服务（SLS）、消息服务（MNS）、表格存储（OTS）、API 网关、CDN 等，其特性在于独特的 Callback 机制大大减少开发者对于异步模型的架构和代码成本；

  • 支持语言：阿里云函数计算目前支持主流开发语言如 Node.js、Java、Python，并通过 Custom Runtime 支持 Go、C/C+、Ruby、Lua 语言等；

  • 用户体验：阿里云函数计算提供了基于 Web 的控制台和 SDK ；用户可以通过 Web 控制台管理函数应用，也可以通过交互式的命令行来操作；

  • 服务模式：函数可以被服务和应用管理，单个函数实例可以并行执行多个请求，有效节省计算资源成本。

棘手的难题

Serverless 的痛点很棘手，例如传统项目如何快速迁移到 Serverless ，如何平滑过渡，如何 Serverless 化， Serverless 架构下如何进行更优的调试，如何更好地节约成本等，每一个都是难题。我的同事许晓斌在《喧哗的背后：Serverless 的概念及挑战》一文中曾提到落地 Serverless 面临的挑战：

在主流的场景大规模的落地 Serverless，并不是一件容易的事情，面临的挑战有很多，下面我具体分析一下这些挑战：

挑战一：业务轻量化困难

要实现彻底的自动弹性，按实际使用资源付费，就意味着平台需要能够在秒级甚至毫秒级别扩容出业务实例。这对基础设施是一个挑战，对业务，尤其是比较庞大的业务应用来说，更提出了很高的要求。如果一个应用的分发和启动需要十分钟，那么自动弹性的响应能力就基本无法跟上业务流量的变化了……

挑战二：基础设施响应要求极高

一旦 Serverless 的应用或者函数的实例能够实现秒级，甚至毫秒级扩容，相关基础设施就很快会面临巨大的压力。最常见的基础设施就是服务发现和日志监控系统，原本整个集群实例的变化频率可能是每小时几次，现在这个频率变成了每秒几次；此外，如果这些系统的响应能力跟不上实例变化的速度，那么整个体验也就大打折扣了。

挑战三：业务进程生命周期与容器不一致

Serverless 平台依赖标准化的应用生命周期，才能实现完全自动的容器腾挪，应用自愈等特性。而在基于标准容器及 Kubernetes 的体系下，平台能控制的生命周期就是容器的生命周期。因此就需要业务做到业务进程的生命周期和容器的生命周期保持一致，具体包括启动、停止、以及 readiness probe 和 liveness probe 的规范等等……

挑战四：可观测能力需完善

在 Serverful 的模式下，如果生产环境出现任何问题，服务器是不会消失的，用户会很自然的想到登陆到服务器上去。到了 Serverless 模式下，用户不需要关心服务器了，也就是说默认情况下是看不到服务器了，那么这个时候如果系统出现异常了，而且平台无法完成自愈怎么办呢？……当围绕 Serverless 模式的全面可观测能力不足的时候，用户必然不会对此感到放心。

挑战五：研发运维心智需要改变

几乎所有的研发，在职业生涯中第一次部署自己的应用程序的时候，都是面向一台服务器的，或者说是面向一个 IP 的，这是一种非常强大的习惯。在 Serverless 逐渐落地的过程中，研发需要转换一些思维的模式，逐步地去适应 “IP 随时可能会发生变化” 这样一种心智，转而更多的从服务版本，以及从流量的视角去运维自己的系统。

打个比喻，Serverless 目前确切来说已经有了一个形态，也就是有一个框架，但是这个框架里还有很多格子（问题）没有被填满（解决），这也是大家今天对是不是该用Serverless 存在疑问的地方，原因之一是还没有看到足够多的成功案例。**但事实上，阿里在2019年双十一就已经成功实践了 Serverless。不仅如此，阿里云还带动了一批企业使用函数计算产品，从而节省了大量的 IT 成本。 **

"成为用户需要的 Serverless"

函数计算有几个非常典型的应用场景，比如 Web 应用、AI 推理、音视频处理、图文处理、实时文件处理、实时流处理等，目前函数计算拥有大量的客户群体，如石墨文档、芒果TV、新浪微博、码隆科技等。

以微博为例，函数计算平均每天承载微博几十亿次请求，其毫秒级伸缩计算资源能够确保在热点事件发生时，应用仍能保证稳定的延时，用户体验完全不受访问次数的影响。通过函数计算运行图片处理服务，微博实现了持续的成本节省，再也不需要为平滑处理业务高峰带来的流量激增而提前预留大量闲置机器资源，同时由于不需要维护复杂的机器状态，工程师可以集中精力与产品团队合作增加业务价值，而不是花时间管理基础设施。

不仅像新浪这样的早期互联网企业已经落地 Serverless，一些新兴的创业公司也正在加入 Serverless 阵营。

蓝墨是一家由美国留学生回国创业的高科技公司，专注于移动互联时代数字出版和移动学习领域的新技术研究及平台运营。随着在线教育迎来需求爆发，蓝墨加大了整合业界优质课程资源的力度，不断拓展自身的业务边界，在赢得机遇的同时，技术团队也面临了前所未有的挑战。

视频处理相关业务是蓝墨技术团队遇到的最棘手的问题之一。蓝墨每天都要处理大量视频教材资源，涉及到视频剪辑、切分、组合、转码、分辨率调整、客户端适配等一系列复杂的技术工作。在前几年的技术实践中，蓝墨技术团队通过 FFmpeg 等技术已经建立起一整套自主可控视频处理机制，支撑了业务的快速发展。但今年的业务增长速度是蓝墨的工程师们始料未及的，高峰期数十倍于往年的视频处理需求让现有的架构不堪重负，严重影响了用户体验。

蓝墨现在的核心诉求概括有三个：节省成本、极致弹性、免运维，而这些恰恰是 Serverless 最擅长解决的问题。经过对国内云厂商提供的 Serverless 服务的多方面调研后，蓝墨技术团队一致认为在视频处理领域阿里云函数计算是最适合他们的方案。

由于 FC 完全兼容现有的代码逻辑，也能够支持各类主流的开发语言，**所以蓝墨技术团队可以把代码逻辑以近乎无缝衔接的方式从原有的架构迁移到 FC 上，并且成本极低。**通过对接 OSS 触发器，只要 OSS 上有新的视频源文件上传，就能自动拉起函数计算实例，开启一次视频处理业务的生命周期。

通过整合 Serverless 工作流，还能对分布式任务进行统一编排，实现对于大文件切片后进行并行处理并最终合并的复杂操作，能够在短时间内迅速调集上万个实例的计算资源，实现视频处理任务的快速执行；

另一方面，相比于传统的方式，基于函数计算 FC 的 Serverless 方案在视频处理场景下，可以帮助蓝墨节省了 60% 左右的 IT 成本投入。

下一个十年的主战场

理想中的 Serverless，应该是：更完善的产品形态，更极致的弹性能力，更好用的工具链，更节约的成本，更高效的开发效率，更便捷快速的迁移速度，更简便强大的上云体验。要做到能让开发者以一种方式专注于业务代码的开发，无需关注运行平台的差异性，一处编写可以处处运行，开发者只要掌握一种方式就可以在不同业务之间没有学习成本地切换。

站在开发者的视角，Serverless 的整个研发模型对研发体系也带来了挑战。对于前端来说，Serverless 不仅补足了前端工程师现有的能力，还可能使整个前端行业的定位发生变化。原来经常有人会认为前端的工作很简单，面向 UI 做好开发就行，剩下的工作可以交给后端。但是前端和 Serverless 结合之后，大家对前端的诉求就不仅仅是开发一个页面了，而是要能交付整个应用的开发。

但是相应来讲，后端同学可能第一反应就是，那这是不是把我革命了？我就不需要干活了？其实不是这样的。Serverless 研发模式的演进有助于帮助他们往更底层演进，让他们聚焦于真正需要做技术研究的部分。比如，这些数据的能力、服务的能力，怎么做得更好、更扎实，这是我们期望看到的。

阿里云正在通过工具链、社区以及产品能力的结合，打一张非常有趣且会对Serverless 的整体发展非常有利的牌。阿里云 Serverless 的目标是成为“大家需要的 Serverless ”，这是与其他云厂商截然不同的地方。只有将用户需求放在首位的 Serverless 厂商，才能将 Serverless 产品做好。

未来，Serverless 将无处不在，任何足够复杂的技术方案都可能被实现为全托管、Serverless 化的后端服务。不只是云产品，也包括来自合作伙伴和三方的服务，云及其生态的能力将通过 API + Serverless 来体现。事实上，对于任何以 API 作为功能透出方式的平台型产品或组织，如钉钉、滴滴、微信等，Serverless 都将是其平台战略中最重要的部分。