Concept

Why Cloud Native¶

因此， Serverless 是云原生技术发展的高级阶段。

上一家单位还处在 Data Centre 阶段，而今我在研究 Serverless, 看来我进化了。

关键词：no server，stateless，event-driven

如果你的PaaS可以将以前半秒启动的应用在20ms内启动，就叫它Serverless。——Adrian Cockcroft

大部分 PaaS 应用不会为了每个请求都启动并结束整个应用，而 this is what FaaS does。

从外延来看，Serverless 比 FaaS 的外延要广，FaaS 主要解决的是用户自定义的代码逻辑如何做到 Serverless，可以叫做 Serverless Compute。

有张老图找不到了，下边找了一张 Spring Serverless 官网介绍页的图代替，意思差不多。

目前业界的各类 Serverless 实现按功能而言，主要为应用服务提供了两个方面的支持：函数即服务（Function as a Service，FaaS）以及后台即服务（Backend as a Service，BaaS）。

Faas 的主要概念是，将使用云服务的过程变得和传统编程一样：一个应用由很多个函数组成，每个函数有输入输出，在函数内完成必要的逻辑。开发者只需要编写好函数代码，将代码注册到云端，将这些函数组成一个完整的应用即可。

BaaS: 通过 BaaS 平台将应用所依赖的第三方服务，如数据库、消息队列及存储等服务化并发布出来，用户通过向 BaaS 平台申请所需要的服务进行消费，而不需要关心这些服务的具体运维。

其中，

状态管理
冷启动延迟
本地测试
不适合处理复杂的业务逻辑，它更适合调用云上的其他服务，粘合关键的产品。
排查问题困难，因为逻辑散落在各处。
Serverless调用之间不能共享状态让编写复杂程序变得极度困难。
业务拆分问题。
对已存在的项目迁移困难。将现有的复杂的单体式应用进行如此细粒度的拆分需要极高的成本。
厂商锁定。云计算是赢者通吃的行业，大而全的云厂商优势巨大，Serverless加剧了这种趋势。以前用户还需要自己写很多服务器端的逻辑，迁移的时候，把服务器端代码重新部署一下。采用Serverless架构之后，代码都是各个平台的Lambda代码片段，没法迁移。从客户的角度来看，是不希望自己被某家云厂商所绑架的。所以云计算行业需要做很多标准化的工作，方便用户无缝在各种云之间迁移。

Serverless 的优势和局限性决定，适合以下场景：

示例：

Serverless 还是继承了微服务的优势，并且适用于无状态的、基于事件的处理，这是两者共同点。
- 但是Serverless的粒度更细，弹性更好：微服务的迭代发布一般以天或周为单位，每个微服务代码量在几百行左右；如果采用了容器化微服务，可能秒或分钟量级。
- 而对于Serverless业界一般会定义为毫秒级别的弹性指标，大部分都是基于内存存储或者事件处理。
相比于虚拟机等底层技术具有普适性，Serverless靠近使用者、偏上层，这也就意味着Serverless有一定的局限性和适用范畴。
- Serverless适用于轻量、事件驱动的技术框架，比如Java 9中类似与React的方式。
- 传统三层架构，如大量文件处理、传统关系数据库的操作，体现不出来太多的优势。
Serverless比微服务更细化了，管控起来会更麻烦，因此是不可能依靠人工去执行的，进行一个个函数的管理，一定需要借助平台。

serverless 本质上是一个问题域，将研发流程中非业务核心确影响业务迭代的问题抽象化，并提出相应的解决方案。
Serverless 语义下的自动扩缩容是可以让服务从 0 到 N 的，但是 HPA 不能。HPA 的机制是检测服务 Pod 的 metrics 数据（例如 CPU 等）然后把 Deployment 扩容，但当你把 Deployment 副本数置为 0 时，流量进不来，metrics 数据永远为 0，此时 HPA 也无能为力。
所以 HPA 只能让服务从 1 到 N，而从 0 到 1 的这个过程，需要额外的机制帮助 hold 住请求流量，扩容服务，再转发流量到服务，这就是我们常说的冷启动。
所以，更好更快的冷启动是 serverless 平台追求的极致目标。