“Less is more”是路德维希·密斯·凡德罗在建筑领域提出的观点，近些年来，这一观点不断被用于生活中的其他领域。在软件开发世界中，也有对“Less is more”这一观点的架构理念，这就是如今逐渐盛行的“Serverless 架构”。

十多年前，主流的应用架构都是单体应用，当时的开发者们既要关注所需的计算、存储资源，还要关注最底层的服务器等资源，同时当企业业务规模开始激增，导致开发和运维难度更大。随着容器技术的衍生及应用，虽然用户可以从对基础服务器关注中抽离出来，但其投入的运维精力依然绕不开的是与业务相关的 CPU、内存、网络等资源。

如今在资源投入、架构理念、架构模式向越来越精简，越来越“物尽其用”的演进中，Serverless 可以说是“Less is more”的最佳实践。它让开发人员不再操心运行所需的资源，精简自己的开发流程，将关注点重点放在产品代码、业务逻辑上，同时只需为实际消耗的资源付费。它使得程序开发架构中只保留了重要的、有价值的资源；其余的资源要么从开发主体中精简剔除，要么隐藏在选择性可见的界面中，用户随用随取。

Serverless 是“速度”与“激情”的再现

Serverless 是随着云计算、虚拟化的延伸发展历程演进而来的。有人说，未来将是 Serverless 的天下。那么，Serverless 究竟有哪些优势，使得它受到开发者们如此高的重视呢？

节省维护成本，可实现自动伸缩

首先，Serverless 是一个基于云的服务，服务提供者帮助处理了服务器端的基础 IT 工作，比如把云部署从 x86 机器码（99% 的云计算机使用 x86 指令集）提升到了高级语言层面、管理操作系统、数据库版本升级等等。因而开发者们只要编写代码并部署它即可，不需要处理任何后端服务器的任务。

同时，相比于传统的非 Serverless 架构，这种架构模式带来的另一大优势是，开发者无需为过度配置或意外的负载峰值提前做好分配计划。因此，在企业级架构侧常常会遇到的服务伸缩性等问题，Serverless 也可以做到自动伸缩，或方便开发者对容量进行简单的手动设置。

节省人工成本，复杂工作都可以交给机器

一方面，Serverless 有相对标准的编程环境，减少了对服务器和容器部署所耗费的操作成本。另一方面，在所有的应用程序架构中，Serverless 应用程序拥有的代码量最少，且恰当的 Serverless 架构在相互依赖性上较少。

对于开发者来说，这意味着更少的开发逻辑，用更少的代码来定义开发、测试、部署、运维。另外从应用程序角度来看，无服务器的功能基本上是一种外部服务，它不需要紧密集成到应用程序的容器生态系统中。

缩短交付时间与周期，节省开发成本

随着产品及软件版本迭代周期的速度越来越快，一些云厂商在面向客户的咨询调研中发现，越来越多的客户已不满足于缩短开发与测试的周期，而是需要更短的交付周期——从新产品或功能的概念化到以 MVP 部署到生产环境的整个时间。

在应对该问题的解决方案上，Serverless 提供了巨大的作用。部分客户在使用该架构及应用程序后，能实现在几天时间内完成项目的部署。

总的来说，Serverless 可以称得上是当前各类新架构中“激情与速度”的再现——在降低人工成本、降低风险、降低基础设施成本、提高扩展性、缩短交付时间上，都形成了绝对的杠杆力。目前，Serverless 的适用场景非常广泛，或者说它或将成为大多数交付链中的一部分。

不过，必须要提的一点是，Serverless 所具备的优势并不等于它是万能的。很多开发者基于对 Serverless 优势的理解，容易陷入“它是容器替代方案”的认知误区。而实际上，Serverless 与容器针对的是不同的用户需求。

AWS Serverless 的基础技术革新之旅

1.Lambda 开启 Serverless 商业化进程
Serverless 商业化进程的真正开启，起源于 AWS 在 2014 正式推出的 AWS Lambda 计算服务。随后，各大巨头也都相继推出了相关服务，遂而将 Serverless 的市场竞争推向白热化，Serverless 是云服务商提供云服务能力的试金石，如何兑现向客户承诺的 Serverless 构建能力，需要云服务商的众多云服务能力作为支撑。

Lambda 的诞生，可以说是云计算技术的一次跃进式发展。正如上文所说，让开发者从对虚拟机、服务器机群容量、集群扩展这些细碎的关注点中抽离出来，Lambda 帮助其真正实现了按需执行、按需计费、按需自动弹性扩展和高可用能力。

值得一提的是，一些人更喜欢用缩写 FaaS(Function as a Service，函数即服务) 来描述 Lambda 这类技术，对于无服务器技术来说，FaaS 只是无服务器技术和架构中必须提供的众多能力中的一种。但 Lambda 是 FaaS 的典型代表，它允许用户仅仅上传代码而无需提供和管理服务器，由它负责代码的执行、高可用扩展，支持从别的 AWS 服务或其他 Web 应用直接调用等。

Lambda 能和大量的 AWS 服务进行整合。这里，我们将 AWS Lambda 放在若干个实际应用场景中，来向开发者们解释，基于它，能构建哪些内容，并如何和 AWS 的其他服务进行联动应用，加速开发。

数据处理与操作

Lambda 和 AWS 服务非常适用于构建用于处理数据的事件驱动管道。开发者可以使用 AWS Lambda 执行代码以响应数据更改、系统状态变化或用户操作等触发器，AWS 中的 S3、Amazon DynamoDB、Kinesis、SNS 和 CloudWatch 等服务，都可以作为 Lambda 的直接触发“机关”。

在数据处理管道中，许多用户会遇到数据上传后需要得到立即处理的场景，例如需要将视频从一种格式转换成另一种格式，或者即时调整图像大小以匹配不同设备。Lambda 则可以实现实时创建缩略图、转换视频代码、聚合和筛选数据等，并且可以由 S3 或 Kinesis 触发。

实时数据流处理

很多 AWS 用户会使用 Lambda 和 Kinesis 处理实时流数据，从而跟踪应用程序活动、处理事务处理顺序等。其中，Kinesis 服务可以对数据（如日志、系统事件、用户点击等）的摄入进行处理，Lambda 函数则可以对数据流中的新记录做出反应，并能快速处理、保存或丢弃数据。
Lambda 和 Kienesis 的组合很适合会产生大量需要被分析、汇总并存储数据的应用程序。在应用程序产生的大量数据中，Lambda 可以随负载自动扩展和缩减，月度处理数据点可达百亿级。

后端

Lambda 还被用于构建无服务器后端，以处理 Web、移动、物联网（IoT）和第三方 API 请求。在很多客户场景中，可能会通过无服务器架构将前端直接连接到数据库，允许前端与服务进行安全通信，这里面只要通过 API Gateway，即可调用 Lambda 函数，Lambda 函数可以执行自定义任务并与其他服务通信。

2.Fargate 与 Firecracker 的诞生——Lambda 在“进化”
Lambda 所具备的丰富特性和应用场景的背景，让其成为一度流行于 FaaS 届的、可以称得上完美的方案。实际上，Lambda 当然也存在一些缺点与问题。例如迁移难度大、自动扩展性差、应用语言种类较少、计算规模受限、冷启动（函数未被运行一段时间后需要重新启动容器运行，而造成的函数调用被延迟）、不断膨胀的代码库维护等。

直至 2017 年年底的 AWS re:Invent 大会上，AWS 宣布针对容器的无服务器计算引擎推出 AWS Fargate，云计算技术尤其是 Serverless 架构和应用的演进，才算真正迎来了一次新的机遇点。

Fargate 不仅可以抽象出运行容器的服务器，还可以提供服务器编排的抽象，作为容器的免编排计算。
这也意味着，当 K8s 等容器编排工具的使用度越来越高，乃至成为开发中的一项“基础设施”时，开发者们可以将创建和管理容器的事情交给云服务商（Fargate）来处理，就好像今天的服务器虚拟化一般，容器也越来越“隐形”。

此外，相比于 Lambda 在自动伸缩、灵活定制资源等特征，Fargate 还可以通过与其他 AWS 服务（包括 Amazon CloudWatch Container Insights）的内置集成获得开箱即用的可观测性。Fargate 可以让开发者通过具有开放式界面的大量第三方工具来收集指标和日志，从而监控应用程序。

随后 2018 年的 AWS re:Invent 大会上，AWS 又开源了 Firecracker——AWS 容器安全沙箱的基础组件。它是 AWS 针对无服务器计算设计的虚拟化技术（利用 KVM 的新虚拟化技术，专门用于创建和管理多租户容器以及基于函数的服务）。目前，Firecracker 已为 Lambda 和 Fargate 在内的多个高容量 AWS 服务提供支持。Firecracker 诞生的内因，也是 Lambda 演进的结果。

从 Lambda 到 Fargate，再到 Firecracker，显示了 AWS 在 Serverless 架构等"基础服务"方面的革新能力。对于用户而言，这些服务的提供，正在让开发者逐步对其带来的安全、高性能、低开销等特性感知更加明显。

更多服务及工具，帮助开发者更高效地上手 Serverless

当然，除了 Lambda、Fargate 这类计算类服务外，AWS 可提供与之相关各个维度的一系列完全托管的服务。开发者可以使用这些托管服务构建和运行无服务器应用程序，从而解决一些特定问题。这里，我们列出了一份服务清单：

以上分类及工具清单来源于 AWS 官网（ https://aws.amazon.com/cn/serverless/ ）

有了 AWS 上述服务的支持，开发者无需为后端组件（如计算、数据库、存储、流处理、消息排队等）预置、维护和管理服务器。同时，应用程序的容错能力和可用性也可以变得更强。

此外，AWS 及合作伙伴生态系统也在开发者工具上提供了多样化使用组合，包括框架、软件开发工具包、IDE 插件和监控解决方案等。

例如框架层面，AWS 兼容了 AWS SAM（用简单方式定义 Lambda 函数、API、数据库以及事件源映射)、Apex、Chalice 等近十款 AWS 自研、开源或第三方的框架供开发者使用。持续集成和部署层面，AWS CodePipeline、AWS Serverless Application Model、AWS CodeBuild 等一系列工具可以帮助开发者自动化构建、测试和部署无服务器应用程序。监控及日志记录与诊断层面，也有 Amazon CloudWatch 和 AWS X-Ray 等辅助进行函数性能监控或故障排除。

归纳来看，无论是扩充提供不同的服务还是丰富的开发者工具，AWS 都是尽可能地帮助开发者在应用 Serverless 架构的过程中，降低其遇到不同场景下处理复杂问题的难度，从而让为“高效”而生的 Serverless 技术能更高效的让开发者上手，更高效的解决问题，从而带来更高效地用户体验。

最后要提的是，Serverless 是利用云的要素帮助用户实现价值交付的颠覆式创新。

因为用户价值交付涉及方法论、开发者工具、应用交付体系、商业模式设计等多个维度，所以 Serverless 是顶层设计的产物。它并不是任何企业在任何场景下都必须要“跟风”应用的时髦技术，毕竟它从真正诞生到至今应用，还只有短短 6 年而已。开发者们一定要选最合适，而非最流行的架构方式。

而一旦当你下定决心全面应用 Serverless，也一定要在这项新兴技术得到普及之前，学会借助实用的服务或工具来应对复杂问题，进而帮助你更快地创建高效、高性能的新架构及软件系统，让你的“酷想法”更快成真。

创作场景

开发运维配置繁杂，是时候给应用架构做减法了