简介：极客时间《Serverless 入门课》作者秦粤最新文章: 再次讨论正当时的 Serverless。文章分为三个部分，分别是 复杂化for 云开发商; 简化 for 开发者，以及团队使用 Serverless 的最佳场景。
作者说
在开始本篇内容前我想与各位开发者达成几个共识。
第一个共识，软件工程没有银弹， Serverless 也不是银弹，它并不是解决所有问题的万能公式。
第二个共识，Serverless 能够解决的是运维域的问题，它是解决特定领域问题的一个技术，并不是无限延伸的，与低代码没有关系。
第三个共识是复杂度守恒定律-泰斯勒定律（Tesler’s law）。典型例子就是苹果，苹果的产品很容易上手操作。但本质上它整体的复杂度是守恒的，它其实是把复杂的事情留给了系统开发工程师和软件开发的工程师，让用户可以顺滑体验。同理 Serverless 也是如此，把部署 or 运维应用、网站的烦复转交给了云服务商，但整体的复杂度是不变的。
第四个共识是邓宁-克鲁格效应（The Dunning-Kruger Effect），大家在认知学习过程中，都会出现这样的发展曲线：从刚开始一无所知，到对新知识的幻想，再到失望的低谷，缓慢爬坡。我们学习任何一个新事物都会经历这样一个曲线过程。Gartner采用邓宁-克鲁格曲线，来解释新技术的发展周期。
作为开发工程师经常会有这种体感，新的技术层出不穷学的很累。Serverless 刚推出来时也一样，大家对这个技术充满了无限的想象，当想象到了一个巅峰以后，会慢慢认识到想象与现实的差距，切身去体会在产品中使用时就会掉到技术的低谷，然后再缓慢的爬坡。
Serverless 正当时
本文将会通过三个部分，为各位介绍 Serverless：
第一个部分是“复杂化 for 云开发商”
第二个部分是“简化 for 开发者”
第三个部分，会介绍一些我自己和我们团队使用 Serverless 时的最佳场景。
1、复杂化 for 云开发商
(1) Serverless 架构
CaaS 的实现的方式有很多，Serverless 应用底层必须有CaaS服务的支撑。除了Docker以外，vm 也可以是 CaaS ；例如 Node.js 的 vm 也可以做 CaaS ，webassembly 也可以做 CaaS 等等。另外在做整体架构设计的时候，还需要一个 Component 层去解决网络东西流量和南北流量的问题，例如service Mesh和ingress的方案，总体来说 Serverless 背后的架构设计基本都是如此。
(2) 云开发商：不可变基础设施
CNCF对云开发商来说会有vendor-unlock的危机，当所有云服务作为不可变基础建设，复杂度下沉到K8s层，架构变得通用。因为CNCF的架构整套框架是根据配置文件去迁移的，可以部署在阿里云、也可以腾讯云、亚马逊的云上，甚至自己搭建的私有云。
另外对云服务商来说，他们以前积累的传统的优势(虚拟机 laas 层的运维优势和 Caas 层的平台级的优势）就会渐渐失去。所以如果是 vendor-unlock 云服务商之间就会白热化地打价格战，看谁能提供更好更便宜的服务。
狭义的 Serverless 不仅仅是 Severless Computing，还指一个 FaaS 的应用，是由 trigger（也可以归并为BaaS） + FaaS+ BaaS 的架构组成的。现在云开发商在 Serverless FaaS 的这一层的核心竞争力是不断推出新的 BaaS 能力，而 BaaS 主要是跟 FaaS 配套去使用的。
上面讲到的云服务商的不可变基础建设，如下图所示，开发者在最上面这层去部署应用，根本不用关心底层的这些基础建设。现在云服务商提供的 Baas SDK实际上已经包含在你的这个 FaaS 的runtime里面，开发者只需要把它当成一个函数接口去直接调用，不用关心数据库部署在什么地方、要不要保持长链接等等。
2、简化 for 开发者
为什么最近这几年没有什么特别新的东西推出了？原因在于 Serverless 这层没有特别新的概念诞生，大家更多是在做FaaS应用基础建设。现有的各种Web应用场景场景是否可以Serverless化，比如近期已经支持了的，数据库 BaaS 化， websocket 支持 FaaS，另外还有很多Web应用场景都是通过诸位的努力慢慢爬坡实现，使其能够接近理想中的 Serverless 。
图中画框的位置就是 Serverless，绿色代表已经成熟，可以看出，现在的 Serverless 已经是一个比较成熟的技术了，支持大部分Web应用的场景了，所以各位开发者大家可以放心大胆地去尝试Serverless。
(1) 运维领域的 Serverless
传统的模式的前后端开发模式是由：后端提供数据服务，以前叫 SOA 是面向服务的编程，现在比较流行的是领域驱动微服务，前端消费组装数据。后端数据接口传统的方式是提供 HTTP API，到现在的流行的 BFF (Backend For Frontend) 胶水层函数编排。配合微服务提供全量数据，是目前业界比较流行的做法。那么未来的趋势将会全部 BaaS 化，理想的状态是前后端一体化模型驱动，不再需要再写接口。
结合 Serverless 做技术变革
当下 Serverless 所处的阶段的优势是跟其他领域的技术结合， Serverless 结合其他领域来引爆许多技术变革。例如，传统的微服务 + Serverless 结合起来后，可以做成 BaaS 化微服务。以前提供一个微服务，是需要开发者去关心这个微服务部署在哪里，但是加上 Serverless 后，便不用管部署在哪里，只需要关心怎么去调用即可。LowCode 加上 Serverless 可以让搭建出来的页面快速部署并上线；之前的接口函数编排如传统的 BFF，在未来都可以 Serverless 化，变成SFF（Serverless for frontend），很适合做前后端一体化方案。
（2）开发角色的转变：前后端一体化
Serverless 出现后，未来还会出现前后端一体化的局面。现在已经出现逻辑编排可视化的工具，例如狼叔的 iMove ，目前已经可以做到后端接口的可视化编排，前端工程师去做一个后端的接口编排变得非常简单。由此可以预见，前端工程师未来的职责可以往后端去延伸。
3、Serverless 的最佳场景实践
对于 Serverless 使用最近场景的判定，最便捷的方式就是去看云开发商支持哪些 Trigger 事件触发。
另外Serverless的现阶段，开发语言的重要性没那么高了，语言只是去实现功能所需要的工具。CNCF 推出来以后 FaaS 就已经是与语言无关的了，那么其实到底是Node.js，PHP，Python 亦或是其他主流语言的代码FaaS都可以，你甚至可以自建一个镜像自定义语言和执行环境。因此在Serverless后，多语言的优势我们都可以借用，比如用Python去处理AI数据，Node.js去处理高并发网络I/O等等。
（1）SFF 数据编排
最佳实践就是 BFF + Serverless，这在阿里集团内部是十分常见的。由于阿里内部的大多场景后端都是 Java 工程师，前端团队需要跟工程师去对接，而后端工程师提供的就是HSF微服务，可以把它理解为一堆 RPC 接口。以前就是部署一个 Node.js 应用去调接口，拿到数据后对这些数据进行是清洗、处理，放到前端页面去渲染。但是采用 Serverless 部署BFF的Node.js应用后，基本不需要考虑跟进流量扩缩容、节省成本等问题。
GitOps 对于小企业来说，是非常适用的场景，相当于可以自建一套自动发布上线的管道，不再需要像以前一样，修改一个版本便要测试一遍，目前整个方案已经十分成熟了。Git 本身支持大量的 hook 函数，所以打造这样一个流程也是非常容易的。需要关注的是要结合云开发商的能力，比如阿里云发布流程便十分自动化，在云下平台发布上线后可以支持线上的流量录制、回放。
最后一点是打造小而美的团队。在我的认知中，技术架构有个强大制约就是：组织架构会决定我们的技术架构。
就像前后端分离，大多是因为组织架构定义了：前端有前端的领导，后端有后端的领导，所以就会产生前端由前端的开发，后端由后端的开发，需要中间去联调基于API沟通。那我们如果要想打造一个小而美的团队怎样打破这个隔阂呢？
Serverless 一个比较适合的场景就是，通过前端的服务编排 SFF 将解决掉中间API沟通的问题，后端去提供全量的服务即可。这种变革会迫使后端去做微服务化，甚至后端研发采用Serverless 去做 BaaS 化，这是反向的导推过程。如果我们的前端团队掌握了 Serverless， 有三个优势：前端的数据编排便不再需要再找后端工程师了；GitOps 解决部署运维，可以降低前端心智负担；前端同学能够专心抽象业务模型。
作者简介：
蒲松洋，花名秦粤。极客时间《Serverless 入门课》作者。Serverless 和 Node.js 布道者，目前负责阿里巴巴前端委员会标准化小组，低代码小组--中后台搭建，Node.js 应用微服务架构。在微服务、Serverless 以及中台项目中有着丰富经验。
本文为阿里云原创内容，未经允许不得转载。