前言
随着 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 产品进行进一步的链接，使其不是“混杂在诸多产品中的某些产品”，而是“可以联合起来解决某个问题的具体功能”，换句话来说将不同的产品联合到一起，以应用的维度为开发者提供场景化支持，这也是 Serverless 架构从资源朝着应用，再朝着业务发展的必经之路。
目前 AWS，Azure，Vercel，以及阿里云都已经逐渐推出“应用的概念”，试图以计算平台和核心，通过BaaS 产品的联动，让本来“杂乱的花园”，逐渐的变得规矩，有条理起来；让本来需要开发者“痛苦的选择”，逐渐的变成场景化推荐，流程化引导。
产品与功能体验
本次活动是阿里云 Serverless 函数计算评测，所以本文仅对函数计算与其相关产品进行体验，包括函数计算本身（包括三个主要模块：基础模块服务与函数和上层封装模块应用、任务），Serverless 工作流以及开源项目 Serverless Devs。
函数计算
服务与函数
函数与服务的功能如下图所示：
函数计算产品形态为两层结构：服务、函数。
- 服务：一种逻辑关系，表示的是一系列函数以及部分公共配置的集合；即带有特定属性的函数集合；
- 函数：一种确切的资源或业务逻辑；由代码，触发器以及相关的配置组成；
函数计算的两层概念为开发带来了一定的便利，也带来了一定的负担：
- 便利：
- 业务划分更清晰：可以让开发者更清晰的将同类型业务/功能划分在一个服务下，不仅让页面更清晰，也会让管理（包括资源分配，权限划分，账单等）更便利；
- 让环境划分更简单：通过服务将业务进行归类之后，有助于基于服务进行环境的划分。通过服务进行不同环境的划分，相比针对函数进行环境的划分会更便利和更容易被接受；
- 负担：
- 理解成本增加：开发者从其他厂商过渡到函数计算，会产生较大理解成本，例如什么是服务，服务里面包括了什么资源等；
- 使用逻辑混乱：由于服务和函数的层级划分，导致某些属性和使用层级被进一步拆分（例如某些属性，究竟是在函数配置还是服务配置更合理），进而导致用户在某些时候很难找到自己所需要的功能；
函数计算的上手流程相对简单，通过函数计算文档，可以看到整体流程：
即，开发者只需要完成代码的开发和部署，即可实现业务的弹性伸缩和按量付费能力的夹持，这也符合 CNCF 在白皮书中对 Serverless 架构流程定义的规范。通过阿里云函数计算控制台可以快速进行这个流程的体验，点击“服务及函数”选项，就可以看到服务列表：
此时可以根据需要，创建服务和函数：
完成之后，可以在线编辑代码与在线测试：
至此，即完成了函数计算上手，在整个过程中，有几个明显的感觉：
- 从零上手流程还是比较顺利的，只要多关注标注信息，有一些研发经验，是可以快速的创建服务与函数的；
- 函数计算功能相对来说是全面的，包括单实例多并发，预留，版本&灰度，可观测性等，可以满足绝大部分的应用场景，即便某些框架因 Serverless 架构丧失了部分特性，也可以通过产品侧所提供的能力解决；
- 可观测性相对来说很完整，从 trace、log、metrics 等几个方面入手，可以满足开发者在可观测上大部分需求，另外值得好评的是控制台页面的实时日志功能，对开发调试很有帮助；日志搜索功能有待加强，例如若想快速找出日志前后文还需要进一步依赖日志服务等；
- WebIDE 很强大，通过计算资源的分配可以在线进行代码编写和项目构建，但是 WebIDE 的环境和函数计算的环境依旧是不通的，不仔细研读和体验，会被误会在 WebIDE 中的调试即是在函数环境下的调试；
- 函数计算所特有的 HTTP 函数，可以轻松地将 Web 应用迁移部署到 Serverless 架构，但是 HTTP 函数和时间触发器没办法一同配置（在其他云厂商是可以实现的），另外 HTTP 函数和 API 网关触发器的定位有点重复，界限划分模糊，部分 API 网关常用的功能 HTTP 函数没办法实现，API 网关对函数的支持又比较差，甚至在一定程度上要两者配合使用，体验比较糟糕；
- 函数计算的环境变量没有 Secret 能力；环境变量往往涉及到敏感信息，能否加密输出是安全性的一种表现；
- 函数计算有很多代码目录是被限制读写的，但是并不是所有运行时都会被限制读写，这种不对齐会让开发者产生比较大的疑惑，尽管其他厂商也多是这样设计的，但是却没人说这样设计的原因；
- 函数计算从服务到函数，再到可观测、自定义域名等模块，拥有较多功能/配置，目前在使用过程中难以快速找到部分功能。例如经常会找不到预留实例的配置入口等；
任务
除服务与函数，函数计算还有一个模块：任务。
在任务页面的描述汇总，不难看出它实际上是函数的一种变形：
通过创建任务的过程，以及创建任务结束页面：
同样可以验证刚刚的想法：任务的本质依旧是函数计算，只不过：
- 弱化了服务的概念，可以通过简单配置，完成任务创建；
- 本质是函数异步任务的另一种表达，将异步任务抽象成一个可以让开发者快速的创建和发布任务的功能；
由于任务往往是异步的，所以从上游经过函数的处理再传递到下游，整个链路的串联是非常重要的，这也是对云厂商服务一致性与可观测性的一种考验。
通过对任务的体验，整体感觉是比较顺畅的，通过抽象出来的产品化能力，让任务的创建流程和步骤更加精简，可以帮助“特定的开发者快速使用”；但是也会对一些新手用户产生困扰：应用、任务、服务及函数是什么关系？任务和函数有什么区别？
应用
与任务相同的是，应用也是建立在服务与函数之上的；与任务不同的是，应用不仅仅是函数计算。可以认为，应用是函数计算中，联动其他产品的入口或者 Serverless 应用的管理平台。
通过应用创建页面，可以快速体验 Serverless 应用：
可以看到，应用与任务，服务及函数的很大区别在于，应用是场景化非常明确的一个模块，所有的创建过程和导入的过程均是在建设“场景化”的心智。通过应用创建页面，可以看到目前已经有框架、音视频处理等多个场景的应用，以其中的图片压缩为例进行体验：
可以通过引导快速完成应用创建，整个流程最为精简。创建完成之后，可以得到最终的体验页面：
在体验页面中，可以体验当前应用的功能。
应用的出现，无疑是 Serverless 架构多产品逐渐“一起战斗”的表现，即开发者对应用进行管理，而不再是对代码和资源进行分别的管理。通过应用模块，开发者可以：
- 快速体验 Serverless 架构；便于学习和调研 Serverless 架构；
- 可以进行资源联动，并以应用纬度对资源进行管理，对权限进行划分，对业务进行运维；
值得注意的是，应用功能默认有一套标准的 GitOps 配置，通过基于代码仓库进行应用部署之后可以发现应用本身是基于 Serverless Devs 开发者工具实现的，这也充分的将线上平台与线下工具进行联动，在一定程度上可以进一步保证开发者使用体验的一致性。另外，在体验应用模块之后，会产生一些想法：
- 作为产品联动入口，应用模块需要牵扯其他资源投入，如何保证应用模块的资源可以逐渐的“自运营”将会成为应用模块能否成功的关键点之一（所谓自运营指的是不需要某固定团队主动提升应用数量、质量，而是可以由更多参与者自发的去做这项工作）；
- 应用模块在一定程度上应该属于 Serverless 而不仅仅是函数计算，否则过小的 Scope 会限制该模块的持续发展与生态演进；
- 作为拥有标准 GitOps 配置的应用，目前 CI/CD 能力过于单薄；
- 功能不完善，创建后的使用体验有待加强。例如，部署后的“如何应用”的引导、可观测要如何去做 ......
Serverless 工作流
Serverless 工作流在一定程度上可以认为是任务模块的一种升级表现。即单纯的任务模块是基于函数计算的，是异步的，Serverless 工作流在此基础上增加了编排能力：
通过 Serverless 工作流夹持的任务将会：
- 具有服务的编排能力；
- 支持长时间运行流程；
- 可进行流程状态管理；
在体验 Serverless 工作流之后，也有一些思考：
- 与应用模块一样，如果 Serverless 工作流定义的 Scope 过小，可能只是函数计算的编排，会让这个功能丧失很大的竞争力；
- 工作流的整体体验是比较顺畅的，但是相比 LowCode 等平台的编排体验，是弱了很多。如果可以将功能持续优化，将 LowCode 的很多编排体验进行结合，工作流的易用性会更高；
Serverless Devs
目前 Serverless 架构和云原生有着“异曲同工之妙”：让架构变得更为复杂。所以一个好的工具对 Serverless 架构有着巨大价值。目前 Serverless 工具流派分为三种：
- 云厂商主导：例如 AWS 的 SAMCLI，例如阿里云的 Funcraft；
- 开源社区主导：例如 Serverless Framework，Serverless Devs；
- 第三方商业公司主导：例如 Serverless Framework， Stackery；
在这三种流派中：
- 第一种无疑是厂商自己支持，自我闭环的最佳选择。但后期发展和突破自身禁锢的成本很高，所以可以看到 AWS Lambda 有很多用户在用 Serverless Framework 等；
- 第二种由开源驱动既好讲故事，又能吸引社区贡献者一起参与贡献；
- 第三方商业公司主导的项目往往带有一定的“再包装”思想，无论是 Stackery 、Serverless Stack（SST），都在以一种更为垂直的场景化思路，打更有针对性的市场；
关于阿里云 Serverless Devs 上手，可分为三个流程：
- 工具安装与配置
- 项目初始化
- 项目开发与部署
由于 Serverless Devs 项目是发布在 Npm 的，所以在安装之前需要开发者先配置 Node.js 开发环境，再通过 npm 工具进行工具的安装。安装完成之后，可以通过 s config命令进行密钥信息配置：
可以通过s init命令，进行案例代码的初始化：
完成初始化之后，可以直接进行业务的部署：
部署完成后，可以通过浏览器打开项目，进行预览：
同样基于这三个流程，Serverless Devs 也是可以快速的与常见的流水线进行集成，目前官方提供的案例包括Github Action，Gitee Go，Jenkins，以及云效等，但是阅读过相关文档后，不难发现，即便是其他的流水线，也是同样的操作流程。
Serverless Devs 开发者工具针对阿里云 Serverless 架构来说，其最大的意义和价值，应该就在于：
- 更大的 Scope，留下了更大的想象空间（当然，利用不好，这也可能是一件坏事）；
- 是产品联动的基础，通过部署编排，组件化模式，让更多产品联动；
- 用户体验升级，可以帮助开发体验阿里云 Serverless 产品，并基于模板案例，快速上手；
从开发角度来看，Serverless Devs 开发者工具解决了 Serverless 领域常见的几个痛点：
- 所涉及到资源和服务比较多，难以在流水线中进行整体的编排和发布；
- “伪命题：Serverless 不需要用户关注操作系统等内容”，但是在实际使用过程中，用户不得不关注系统，因为这会影响项目打包和构建的结果；
- 由于资源过于零散，环境过于独立，Serverless 架构调试复杂度非常高；
同样，Serverless Devs 也有若干的奇怪操作：
- 文档混乱，内容比较多，分布比较零散，关联比较少，导致新手学习成本增加；
- 概念比较多，例如在使用工具的时候要了解组件、应用等概念，让本来概念“爆炸”的 Serverless 架构，概念变得更多；
- 数据结构设计混乱，很多重复的概念以及不对齐的数据结构，让“复杂的Yaml”变得更加复杂，例如工具和函数都有各自的 service；工具的服务与函数对应关系与函数计算本身并不一致；
- 产品联动，“任重道远“，目前只对函数计算有所支持，另外的 Serverless 产品，包括 Servelress 应用引擎，Serverless 容器等并没有得到支持，更多来说是函数计算的开发者工具；
另外，在 Serverless 领域，云厂商做“无厂商锁定”的开发者在一定程度上是一个“伪命题”，Serverless Devs 未来如何把故事讲圆，还需要拭目以待。
下一个代Serverless探索
用户体验相关
进一步的“统一”
天下大同也许是不可能的，但是技术发展的结局，趋于同质化却是一种趋势。
Serverless 架构同样如此，在云原生技术日益发展的今天，Serverless 架构已经不再是单纯的某个产品或者某种形态，他应逐渐的发展成为一种思想。
基于 Serverless 架构所传递的精神，已经有越来越多的 Serverless 产品出现，尽管如今，他们依旧是“单打独斗”的多，但随着时间的发展，这些产品注定会以一种”粘合剂“为核心，统一的，一致的为开发者提供服务。
从加法到减法
虽然 Serverless 架构并没有确切的定义，但他所要传达的心智却一定不是更复杂。如今来看，Serverless 架构所涉及到的概念“多的不能再多了”。以函数计算为例：
- 用户以为“我只需要关注业务逻辑就可以，服务器等底层资源我不需要关注”，但是实际上，用户需要关注运行时的环境，需要在构建和部署的时候大费周章，，需要理解层，需要评估资源使用量，甚至就明确要是用Python3语言，也要再去理解 Custom Container 、Custom、Python3 运行时；
- 用户以为“我只需要交钱，所有弹性交给厂商来负责”，但是实际上，用户需要关注到冷启动，需要针对冷启动优化代码，需要理解单实例多并发，理解弹性配置（包括定时，指标等不同配置方案，还要理解同时配置的生效规则等），除此之外还要考虑到实例上限等问题；
诸如此类事情还有很多，但是归根到底就是，现在的 Serverless 越做越厚，越做越复杂，但是 Serverless 架构所强调的心智，一定是简单、方便。
所以在未来的发展过程中，Serverless架构的发展方向之一，就是做减法，减掉那些”看似合理，却又没有道理的能力“。例如，为什么要透露出各种实例类型（弹性实例、GPU实例、性能实例、按量实例等）？为什么需要配置预留，需要配置弹性策略？
也许，很多为什么现在看来是合情合理，但是站在另一个维度上，他可能就是不合理的，所以做减法，不仅仅是一种勇气，更是一种对技术的挑战，对产品抽象能力的挑战。
不再重复造轮子
不要重复造轮子，貌似是很多程序员的“共识”，但是在如今的 Serverless 架构下，却有两个非常有趣的极端：
- 开源项目：避免造轮子，疯狂的利用现有资源做事情；例如 OpenWhisk，基本就是依靠开源搭建出来的开源项目；
- 云厂商的服务：疯狂造轮子，提出“各种自成一派的奇怪逻辑”；
所以，Serverless 架构的发展在未来一定是一种更为宽容的技术架构，否则，无限的造轮子和定制化，是永远满足不了业务的迁移需求的，因为新造的轮子“基本都是非标的”。
功能探索
云开发模式
Serverless 架构的下一站是什么？这是一个很多人思考的问题。
函数计算仅仅是一个计算平台，可以单打，但也不能独斗，想要更容易被接受，资源的聚合、联动是必不可少的。尽管函数计算的应用模块，在一定程度上正在联动更多资源，但是这也仅仅是管理层面的，开发者所接触Serverless 架构后，开发也是非常重要的一环节，那么云开发模式就值得考虑，事实也证明，无论是 Vercel 还是腾讯云的云开发，再或者是 Firebase 等，其实在一定程度上都是以一种资源联动的开发加管理态共同为开发者来提供服务和支持的，当然，他们也都是非常成功的产品。
低代码模式
Serverless 架构在一定程度上是可以让很多功能模块化的，而模块化的进一步发展，就可能是低代码模式。
基于 Serverless 架构的低代码有望将 Serverless 思想应用到产品建设思想上，模块化的快速部署、更新，平稳发布与下线也都是符合 Serverless 思想的。
总结
Serverless架构，在未来将会像云主机，容器服务一样，成为云计算时代新的基础设施；在对基础设施的维护的基础上，为开发者提供更为场景化的服务有望成为 Serverless 架构突破自我瓶颈的突破口。
在未来，Serverless 将会是一种“形态不统一，但是目标很统一”的技术架构思想，开发者可以以一种更为一致性的体验，快速使用 Serverless 架构构建自己的场景化应用，当然这里的Serverless包括了不同形态的服务，例如数据库、网关、函数计算等。
综上所述，Serverless 架构在不断的发展，Serverless 架构的精神也在不断的更迭，从函数计算到应用，从开发、运维到全生命周期，Serverless架构要回答的问题很多，要做的事情更多。
