回顾架构的演进过程，我们不难发现，研发运维人员正在逐渐地把关注点从机器上移走，不再去管理机器。
其实我们都知道，虽然说是 serverless，但 server（服务器）是不可能真正消失的，serverless 里这个 less 更确切地说，应该是开发者不用关心服务器的意思。这就好比现代编程语言 java 和 python，开发不用手工分配和释放内存，但内存依然在哪里，只不过交给垃圾收集器管理了。称一个能帮助你管理服务器的平台为 serverless 平台，就好比称呼 java 和 python 为 memoryless 语言一样。
但是，如果我们把目光放到今天这个云的时代，那么就不能狭义地把 serverless 仅仅理解为不用关心服务器。云上的资源除了服务器所包含的基础计算、网络、存储资源之外，还包括各种类别的更上层的资源，例如数据库、缓存、消息等。
serverless 的愿景
2019 年 2 月，uc 伯克利大学发表了一篇标题为《cloud programming simplified: a berkeley view on serverless computing》的论文，论文中也有一个非常清晰形象的比喻，文中这样描述：
在云的上下文中，serverful 的计算就像使用低级的汇编语言编程，而 serverless 的计算就像使用 python 这样的高级语言进行编程。例如 c = a b 这样简单的表达式，如果用汇编描述，就必须先选择几个寄存器，把值加载到寄存器，进行数学计算，再存储结果。这就好比今天在云环境下 serverful 的计算，开发首先需要分配或找到可用的资源，然后加载代码和数据，再执行计算，将计算的结果存储起来，最后还需要管理资源的释放。
论文中所谓的 serverful 计算，是我们今天主流的使用云的方式，但不应该是未来我们使用云的方式。我认为 serverless 的愿景应该是 write locally, compile to the cloud，即代码只关心业务逻辑，由工具和云去管理资源。
serverless 的价值
在对 serverless 有一个总体的抽象概念之后，也需要具体了解 serverless 平台的主要特点，同时这些特点也是 serverless 核心优势的体现。
-
不用关心服务器
管理一两台服务器可能不是什么麻烦的事情，管理数千甚至数万台服务器就没那么简单了。任何一台服务器都可能出现故障，如何自动识别故障，摘除有问题的实例，这是 serverless 平台必须具备的能力；此外，操作系统的安全补丁升级，需要做到不影响业务，自动完成；日志和监控系统需要默认打通；系统的安全策略需要自动配置好以避免风险；当资源不够时，需要能够自动分配资源并安装相关的代码和配置，等等。 -
自动弹性
今天的互联网应用都被设计成可伸缩架构，当业务有比较明显的高峰和低谷时，或者业务有临时的容量需求时（比如营销活动），serverless 平台都能够及时且稳定地实现自动弹性。为了实现这个能力，平台需要有非常强大的资源调度能力，以及对应用各项指标（如 load、并发）非常敏锐的感知能力。 -
按实际资源使用计费
serverful 的方式使用云资源，是按占用而非使用计费的，例如用户在云上购买了三台 ecs，那么不管用户实际使用了这三台 ecs 多少的 cpu 和内存，他都需要支付这三台 ecs 整体的费用。而在 serverless 模式下，用户是按实际使用的资源付费的，例如一个请求实际使用了一台 1core2g 规格资源 100ms 的时间，那么用户就只需要为该规格的单价乘以时间（即100ms）付费。类似的，用户如果用的是 serverless 数据库，那么就只需要为 query 实际消耗的资源，以及数据存储的资源付费。 -
更少的代码，更快的交付速度
基于 serverless 架构的代码通常会重度使用后端的服务，将数据、状态管理等内容从代码中分离出去；此外，更彻底的 faas 架构则把代码的 runtime 也交给了平台管理。这就意味着，同样的应用，serverless 模式下的代码相比 serverful 模式会少很多，因此不论是从分发还是启动，都会更快。serverless 平台也通常能够提供非常成熟的代码构建发布、版本切换等特性，提升交付速度。