开发者学堂课程【Serverless Develpoer Meetup 课程：Serverless Developer Meetup 深圳站】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/943/detail/14746
Serverless Developer Meetup 深圳站
前言：
Serverless 从概念的产生到现在规模化的场景有 9 年的时间，Serverless 技术有从低谷到高潮的变化，现在 Serverless 是正当时的状态。
目录：
一.简化 For 开发者:Serverless 带来的生产关系改变
二.Serverless 最佳场景
三.最后:Serverless+团队=打造小而美的团队
四.复杂化 For 云开发商
五.简化 For 开发者
一.简化 For 开发者:Serverless 带来的生产关系改变
前端后延(前后端一体化)，后端下沉(微服务 BaaS 化)，运维云化(CNCF 运维)
Serverless 未来的职责可以向后端延伸，后端功能从传统的应用 Baas 化上线，慢慢的 Baas 化，做服务级别的开发。以前的运维工程师学 CNCF 云延伸。CNCF 可以在任何场景搭建，私有云、公有云、本地环境都可以搭一套架构。以后的运维工程师更偏向于云端偏移。Serverless 对研发生产链带来一些变故。
前后端一体化概念，之前的前后端一体化概念需要更专业的前端工程师做全栈工程师，有了 Serverless 以后前端工程师写后端接口编排非常简单。已经有前端编排可视化的工具。
二.Serverless 最佳场景
1.Serverless 最佳之:事件驱动+FaaS(无状态)+BaaS(状态存储) FaaS 语言无关，各采所长:Node.js,Py,Java,PHP,go,Ruby,Rus
t…自建镜像
Serverless 在缓慢爬坡，Serverless 提供的能力、边界需要了解。了解 Serverless 边界最容易的方法是看云服务端有支持哪些 Trigger 事件驱发。下面例子云服务端支持 OSS，当上传文件到 OSS，上传成功后事件驱发把函数拉起。
在写 FaaS 时与传统的 requst 调用 FaaS 不同，request 包装成 Tigger，所有的 FaaS 在封闭的包裹里，通过 Tigger 唤醒包裹，腾讯语音已经推出了 web socket 的 Tigger。可以用 web socket 与用户建立长连接。用 web socket 唤醒函数可以处理聊天室。云服务商哪些提供 Serverless 化，哪些提供 BaaS 能力。BaaS 与语言无关的。Serverless 可以保证这样做是最便宜的。
2. Serverless 最佳之:Serverless+BFF=SFF 数据编排
前端团队需要和 Java 工程师对接，Java 工程师提供微服务，可以理解为提供 RPC 接口。
3.Serverless 最佳之:Serverless+Git=GitOps
自建一套自动发布上线的管道，不需要像以前修改版本，测试一遍，上线以后流量回归自查一遍。GitOps 整个方案非常成熟，Git 本身支持大量 book 函数，打造流程非常容易。10%验证发布的灰度环境版本，灰度环境版本验证一天或几天没有问题将版本替换掉。发布流程非常自动化。
三.最后: Serverless+团队=打造小而美的团队
前端和后端做得很开，前端有前端的 leader,后端有后端的 leader。所以就会产生前端有前端的开发后端有后端的开发。打造小而美的团队打破隔阂，Serverless 是比较适合的场景，通过 SFF 以后前端可以把服务编排解决掉，前端去导推。
组织架构决定技术架构
用 SFF 隔离后端变化:数据编排交给前端，前后端一体化。GitOps 解决部署运维:降低前端心智负担。
模型驱动+低代码(跑题):前端同学专心抽象业务模型。
未来新的数据增长点数据驱动，前端同学很长时间被认为不适合做业务只是搭建页面，前端同学做模型抽象以页面为维度，将模型抽象划分模块。
当前业务特点建立业务模型数据后，通过模型驱动页面，低代码化不需要用大页面，所有的页面都用可以所见即可的工具搭建。只需要将当业务的前端模型抽象出，用模型驱动。
前言:先达成几点共识
1.软件工程没有银弹:Serverless 也不是银弹;
2. Serverless 解决的是运维域的问题;
3.复杂度守恒定律(Tesler’slaw)--泰斯勒定律:苹果产品;云服务商承受复杂，开发者变简单;
4.邓宁-克鲁格效应(the Dunning-Kruger effect)
整个 PC 的复杂度是固定的，将复杂的工程留给系统的工程师和软件开发工程师，让用户体验非常简单。以前运维应用、网站复杂的通用的能力沉淀给云服务商，用户变简短但整体的复杂度守恒。由失望的低谷缓慢爬坡，Gartner 将这套理论用来做技术发展的曲线。
Serverless 刚推出后对它充满无数的想象，当想象到巅峰时会慢慢意识到并不是想的那样。可以做很多设想当真正做的时候，切身去体会，在产品中使用时会掉到技术的低谷，然后缓慢的爬坡。所有的技术发展都是这样的曲线。前端工程师体感新的工程层出不穷。
四.复杂化 For 云开发商
1.复杂化 For 云开发商：Serverless 运维集大成者
大部分服务跑到容器 CaaS,用 K8S 来调动容器，laaS 是虚拟机，最底层物理机。Serverless 的应用必须跑到这样的架构上，KS 的实现有很多。Component 是解决网络像 Service Mesh 东西流量。基本上 Serverless 背后虚拟的架构都是这样。
2.复杂化 For 云开发商:不可变基础设施
复杂度下沉，CNCF 无缝迁移，vendor-unlock
整个应用的架构是 CNCF 与云服务商无关，可以部署到阿里云，可以部署到腾讯语音上，整个框架与配置文件迁移。云服务商传统的优势会渐渐失去。云服务商非常白热化，要打价格战，看谁提供更好的服务。
3.复杂化 For 云开发商:Serverless 化
云服务商的内卷 BaaS 竞争白热化，新的 vendor-lock
.狭义 Serverless(最常见)
FaaS 应用=Trigger+FaaS(函数即服务)+BaaS(后端即服务,持久化或第三方服务)
·广义 Serverless
服务端免运维=具备 Serverless 特性的云 PaaS 服务
云服务商在面向 FaaS 激烈的竞争，主要提供 BaaS 的能力。BaaS 与 FaaS 配套使用。
图上最上面一层部署，不需要关心底层的基础建设，只需要关心函数怎么去运行，云服务商提供了哪些 BaaS 的能力。在 FaaS 函数里马上创建一个数据库，插入数据写数据，云服务商的竞争不停的提供新的 BaaS 能力。之前在使用 BaaS 能力、数据库能力时面向于 IPv4。
广义的 Serverless 整个的云服务商运维体系 Serverless 化。
