Serverless 并不是一个前端的概念。
Serverless 是把前端思维带入了后端运维。
Serverless 和其他的前端技术不同，它不是为了解决前端的问题而出现。它是云计算的未来，是整个软件和应用架构的未来，它属于每一种类型的应用开发者。
Serverless的内涵就是对全部底层资源和运维工作的封装，让开发者专注于业务逻辑。
开发者优势：
1、改变前后端接口定义规范；
2、改变前后端联调方式，让前端参与服务器逻辑开发，甚至 Node Java 混和开发。
3、大大降低 Nodejs 服务器维护门槛，只要会写 JS 代码就可以维护 Node 服务，而无需学习 DevOps 相关知识。
4、未来服务器部署更弹性，更省钱。
5、部署速度更快，更不易出错。
概念
Serverless 是一种 “无服务器架构”，让用户无需关心程序运行环境、资源及数量，只要将精力 Focus 到业务逻辑上的技术。
这并非指应用架构中是没有服务器资源的，而是通过 Serverless 这种服务形态，用户在使用对应的服务时，不需要关心或较少关心服务器的硬件资源、软件资源、稳定性等等，这些通常已经由云计算厂商提供设施、服务和 SLA 保障，完全托管给云计算厂商。
而用户只需要专注自己应用代码本身，上传执行函数到相应云计算平台，按照函数运行的时长按量付费即可。
当前比较成熟的 Serverless 云产品主要有 Amazon Lambda、Google Cloud Function、Azure Function、AliCloud Function Compute。
架构
Serverless架构由两部分构成，即Faas和Baas。
通过 FAAS（函数及服务）与 BAAS（后台及服务）企图在服务端制造前端开发者习以为常的开发环境
1、Fass（Function as a Service）
函数运行平台：
用户无需搭建庞大的服务系统，只需要上传自己的逻辑函数如一些定时任务、数据处理任务等到云函数平台，配置执行条件触发器、路由等等，完成基础函数的注册。
2、BaaS（Backend-as-a-Service）
后端服务组件：
它是基于 API 的第三方服务，用于实现应用程序中的核心功能，包含常用的数据库、对象存储、消息队列、日志服务等等。
3、核心
Serverless 其实是通过事件驱动的。
当一个任务被触发时，比如 HTTP 请求，API Gateway 接受请求、解析和认证，传递对应参数给云函数平台，平台中执行对应回调函数，配合 DB、MQ 等 BaaS 服务在特定容器中完成计算，最终将结果返回给用户。
函数执行完成后，一般会被 FaaS 平台销毁，释放对应容器，等待下一个函数运行。
优缺点
1、优点
低运维成本。云计算资源。
安全可靠。云厂商保障SLA，代码加密托管，抵御网络攻击。
事件驱动触发。云资源事件触发，Http请求触发。
弹性伸缩。方便扩容，提前应对峰值流量。
按需计费。百毫秒级计费计量。
2、缺点
云厂商强绑定。当你决定使用公有云的 Serverless 产品时，它们常常会和厂商的其他云产品相绑定，如对象存储、消息等等，这意味你需要同时开通其他的服务，将导致你的应用与平台强绑定，迁移成本剧增。
不适合长时间任务。云函数平台会限制函数执行时间，如阿里云 Function Compute 最大执行时长为 10 min，如果你的任务时间超长，那么你需要拆分编排你的函数执行流程，并在一个函数执行结束时唤起另一个函数执行。这将增加编码的复杂度，而且花费上可能高于购买一个长时间运行的实例。
冷启动时间。函数运行时，执行容器和环境需要一个准备的时间，尤其是第一次启动时时间可能会较长。对一个 Http 请求来讲，可能会带来响应时延的增加，产生性能毛刺。
调试与测试。由于本地环境和平台运行环境的差异性，开发者需要不断调整代码，打印日志，并提交到函数平台运行测试，会带来一些开发成本和产生一些费用。
应用场景
1、定时任务
通过时间触发对应的函数任务，完成开发者业务逻辑的处理。
2、数据加工
通过事驱动件机制，在特定的条件下触发，对系统的日志进行整合，或者对多媒体文件进行加工等等。
3、低频请求
用户可以按照频次付费，而无需构建一个应用来应对这些必要的但是量小的请求。
IoT 物联网场景下，大部分是用户对设备的操控，用户对延时的容忍度较高，也是典型的事件触发且低频场景。
4、认知计算
适用于某些 AI 场景，如聊天机器人。