Serverless 学习笔记 (4): 到底什么是Serverless？_服务端运维发展史,从full到less 了解完server,我们再来看less。 我们可以先看ser

到底什么是Serverless？

Serverless 能解决什么问题？

从字面上把它拆开来看。Server 这里指服务端，它是 Serverless 解决问题的边界；而 less 我们可以理解为较少关心，它是 Serverless 解决问题的目的。组合在一起就是“较少关心服务端”。

什么是服务端？

以经典 MVC 架构的 Web 应用为例，服务端是指WEB服务（即负责负载均衡/反向代理的服务）、应用服务（含MVC3层）、以及对应的服务器/虚拟机/容器等。Serverless 解决的问题，就是服务端的运维。

服务端运维发展史，从 full 到 less

服务端运维有一个从 Serverfull 到 Serverless 的过程，Serverfull 就是服务端运维全由我们自己负责，Serverless 则是服务端运维较少由我们自己负责，大多数的运维工作交给自动化工具负责。
史前时代，Serverfull：应用和运维分离，服务端运维纯人力处理。应用开发人员不用关心任何部署运维相关的事情，运维要管理好迭代版本的发布，分支合并，将应用上线，遇到问题回滚。并进行应用监控，如果线上出了故障，要抓取线上的日志给应用开发人员。这样做的好处是：分工明确，应用开发人员可以专心做好自己的业务；缺陷是：运维人员被困在了大量的运维工作中，处理各种发布相关琐碎的杂事。那么，像发布版本和处理线上故障这些工作能不能完全由应用开发人员自己处理，无需运维人员辅助？
农耕时代，DevOps：重复性的运维工作，以及发布新版本或解决线上故障的工作，进行工具化，并提供给应用开发人员运维控制台，由应用开发人员通过运维控制台自己处理，这样服务端的工作变得 Less 了。但是优化架构节省资源和扩缩容资源方案，还是需要运维人员定期审查，能否进一步提升效率，让应用开发人员连运维控制台都可以不用？
工业时代：资源优化和扩缩容方案可以利用性能监控 + 流量估算解决，应用开发人员的开发流程进一步形成一套代码自动化发布的流水线：代码扫描 - 测试 - 灰度验证 - 上线。这样，连运维控制台都不用登陆，只要将最新的代码合并到 Git 仓库指定的 develop 分支，剩下的就都由流水线自动化处理发布上线。这样研发不需要运维，只需要关心自己的应用业务即可，运维人员的工作也全部自动化了，实现了 NoOps。运维的角色存在感越来越弱，需要由运维参与的事情越来越少，大部分工作都被自动化工具替代了，这就是“Serverless”。那么，是不是就不需要运维人员了？
未来：实现了免运维 NoOps，并不意味着运维人员要失业，而是要转型去做更底层的服务，做基础架构的建设，提供更加智能、更加节省资源、更加周到的服务。而开发人员则可以完全不被运维的事情困扰，放心大胆地依赖 Serverless 服务，专注做好自己的业务，提升用户体验，思考业务价值。另外，NoOps 是理想状态，因为我们只能无限逼近 NoOps，所以这个单词是 less，不可能是 ServerLeast 或者 ServerZero。