文章来源：Go Serverless / 原文链接
作者：Anycodes
2009 年，是云计算发展的一个重要时间节点，无论是从概念正式被提出或定义，或者说是概念被广泛认可、被众人接纳，还是说各大厂商开始布局，伯克利发布断言，国内发布云计算白皮书等，2009 年，注定不平凡，它影响的，不是一个时代，而是一个未来。
2019 年，是云计算发展的另一个重要时间节点，因为这一年“真正的云计算被提出”：Serverless！是的，Serverless 最早被提出，并不是 2019 年，但是 2019 年却被众人称之为是 Serverless 发展的元年，因为这一年，Serverless 被更多人认识、接纳，被更多厂商摆到了台面，作为“战略布局”的重点。
从 Serverless 正式被定义，到 2019 年，乃至此时此刻的 2020 年，Serverless 架构的好处，被一众人吹捧到了天上，有的人说 Serverless 提高了开发效率，降低了成本，还有人说 Serverless 免运维，Serverless 是未来，是一切，Serverless First，All Serverless......但是真正项目落地，应用在实际项目中的 Serverless 并没有想象的多。
那么 Serverless 为我们到底带来了什么？他真的是好处多多么？如果是为什么雷声大雨点小？如果不是好处多多，为什么各大厂商加速布局，毫不松懈？对我们，对用户，对开发者，Serverless 到底意味着什么？
Serverless 带来的希望和恐慌
要我说，Serverless 是一个期望。随着去服务器化，越走越远，随着“把更专业的事交给更专业的人来做”这个思路越来越被关注和重视，Serverless 就目前的现状而言，他是一个希望，一个目标，因为没人知道 Serverless 是不是云计算的一个终态，也没人知道 Serverless 的终态是什么。
说实话，我接触 Serverless 的时间并不久，但是也绝对不短，我接触过很多厂商的 Serverless 产品，也看过很多开源的 Serverless 项目，我觉得目前的 Serverless就是一个萌芽，或者说 Serverless 被定义的太狭隘了，他的未来，没人能预知，但是却可以被我们来定义！
从 IaaS 到 PaaS，再到目前的 BaaS+FaaS（还有人说要加CaaS），Serverless 让一些人体验到了更加便利的技术红利。
通过进一步的去服务器化，Serverless 确实让开发者可以最少精力关注底层能力，更多关注业务本身，也确实让运维将自己的注意力进行了极大的转移，同时所谓的弹性能力，也让用户可以更有安全感，更加简单快速的上线项目，也无需过多的担心流量洪峰。但是也正是这样的一系列变化，Serverless 在我给我们带来好处的同时，也给我们带来了无限的恐慌和迷惑。
是的，无限的恐慌和迷惑，这个和刚才说的既矛盾也相符！
Serverless 的弹性能力
首先说弹性能力，不同云厂商的弹性能力是不同的，所谓的 Serverless 毫秒级弹性，也仅仅是大家的愿景，真正的毫秒级弹性，离我们还很远。就算是阿里云，凭借其底层优秀的能力，也没办法在弹性上做到极致，只能说是尽可能的“弹“。为了解决弹性的问题，阿里云甚至还推出了实例预留来做平衡，虽然在一定程度上，取得了比较不错的效果，也满足了绝大部分用户在这个层面的诉求，但是依旧不算是“真正的弹性”。
国内第二阶梯的云厂商，本来能力上就距离第一阶梯厂商有一定距离，要不是依靠超高的成本来做优化（但是这并非长久之计，不计成本的背后，一定是更加惨淡的收尾，toB 公司不计成本只是一时无法一世），要不就只能是避重就轻，不说性能了（作为一个云厂商，不说性能，其实不如啥都不说）。在我之前的文章《Serverless: 2020 年函数计算的冷启动怎么样了》中，我通过公开代码和实际数据进行过一波测试，其结果真的是差强人意，但是不得不承认，阿里云和华为云在弹性这方面确实下了功夫！所以在弹性这一方面，Serverless 给我们的愿景是好的，但是厂商实现这里，真的会让很多人很难接受，尤其是一个项目连续遇到冷启动，我相信“程序员被祭天“是可能的。
关于 Serverless 的 2 个迷思
接下来，就说迷惑大赏：各个厂商为了让用户上 Serverless，为了推广自家的 Serverless 是真的“不遗余力”，是的，不偏不袒，我就实话实说，希望不会被各大云厂商“封杀”！
迷惑 1: 极致弹性，毫秒级启动，彻底消灭冷启动
国内云厂商阿里云，其旗下的 Serverless 产品在宣传其弹性计算的时候，一直在说极致弹性，那么什么是极致？我相信极致的定义，不应该是由厂商定义的，而应该由用户定义。所以，这个“极致”就是一个迷惑。
当然，相对其他云厂商来说，阿里云还算比较保守，在宣传的时候通常会说次秒级弹性，而在国内的 Serverless 环境下，大肆宣传毫秒级弹性的厂商大有人在，真正冷启动起来的时候，都要几秒甚至几十秒，对比之下“宣传太美好，现实太骨感“！
我为什么说用毫秒，次秒级来形容 Serverless 是迷惑大赏第一名呢？因为 Serverless 架构下，冷启动的时间，往往是和你的代码包大小以及一些配置有直接关系，在不提供毫秒/次秒冷启动/弹性能力的前提下，这种宣传就是扯淡，就像买车的时候看油耗，用测试部门给你的油耗来衡量真实油耗，那简直就会被老司机“骂得狗血喷头”，因为这种宣传是不负责任的，在极限情况下的宣传，在实际项目中，必然让用户们大失所望。
同样，那些宣传毫秒弹性的厂商，你们的毫秒弹性是“万事俱备，只差压测”的情况下测试出来的么？我更希望厂商们可以真诚一些，给我们一组数据，而不是一个数据：例如多大的代码包，热启动/冷启动时间范围是多少，我觉得这种真实的对比，才是有意义的，否则过度宣传，过分夸张，损伤的是用户的信任！
迷惑 2: 极速部署
不知道是什么时候，有部分厂商对自己的性能避而不谈，反而高歌“极速部署”，当然，我并不是说极速部署不好，而是我想知道的是“极速”是多极速？1 秒完成部署？3 秒完成部署？还是？部署速度和代码包有关系么？部署速度和网络有关系么？这个极速在什么情况下会体现？在客户端 3 秒部署一个函数和 5 秒部署一个函数对用户的重要程度相对 300 毫秒启动一个实例和 500 毫秒启动一个实例，哪个才是更加有意义的呢？
我相信，云厂商的根本，核心不是做体验，而是做安全，做稳定，做性能。体验固然重要，但是也只能算是锦上添花，作为一个云厂商，底层不稳定，还不如不做云计算！如果压测一波，各种报错，冷启十几秒，那么我觉得，再好的体验，也仅仅是昙花一现，toB 的产品，不对 B 端负责，注定难以前行。
当然，体验层面也确实是一个非常重要的点，例如阿里云的工具链建设的就并不好，百度云我就没找到一个用户交流群，体验层面腾讯做的算是不错，与 Serverless Framework 合作，同时拥有一个社区。但是无论如何，我都希望厂商们不要再对极速部署这件事过分宣传，而是希望把更多时间投入在安全，性能，稳定。就目前来看，阿里云函数计算和华为云函数计算在安全、性能与稳定层面确实做得很好，百度云做的其实也还不错。我个人觉得函数毕竟是要做为“生产力“的，而不是要做”快速部署力的“，生产中不行，你部署再快也没用，我之前做的一个公众号，遇到冷启动能被微信后台判定为“服务器故障，无法提供服务”，这是多么可怕的一件事。体验层面，阿里、华为要加油，
那么 Serverless 到底给我们带来了什么呢？
我仅仅站在一个开发者角度，觉得 Serverless 目前给我们带来的，是一种希望，是一种思路上的解放，是一种全新的解题方案。
就目前而言，我们可以将一些新的业务上到 Serverless 架构，在一定程度上确实可以提高一些工程效率，对后期的运维等也会有一定的好处，毕竟这些算是 Serverless 的优势，这也是众所周知的。至于业务迁移的问题，我觉得我们还是要慎重，虽然说成功上 Serverless 确实可能会不错，但是迁移过程通常是很痛苦的。对原有业务的改造也是有很大风险的。当然如果有某个厂商 Serverless 支持了镜像，我相信，这将会是一个不错的选择，也很期待国内的云厂商发大力，造奇迹！
Serverless 带给我们的，是一种对云计算的全新认识，就目前而言 Serverless 的定义是没有的。有人认为Serverless 就是 FaaS，有人认为是 BaaS+FaaS，有人认为还要加上 CaaS，有人觉得 Serverless 是未来，有人觉得他只是玩具，但是无论如何，一个新的技术/架构出现，大家接受都是需要时间的，我相信 Serverless 在生产力层面表现出的能力，注定会被大规模应用。用伯克利断言中的话：“Serverless 所提供的接口，简化了云计算的编程，其代表了程序员生产力的又一次的变革，一如编程语言从汇编时代演变为高级语言时代。Serverless 计算将会成为云时代默认的计算范式，并取代 Serverful （传统云）计算模式。”
纵观国内 Serverless 架构的发展，可谓是非常缓慢，期待有一个真正云厂商，可以在底层能力上做好，在体验层面做得出彩。如果说，我心中国内的 Serverless 的样子，我希望是，有一家可以集合阿里云的技术，腾讯云的体验于一身。Serverless，未来已来，带给我们的是一种希望，一种翘首以盼的态度，一种 All Serverless 的梦想，Go一起 Serverless！
END
Kubernetes CKA实战培训班推荐：
本文分享自微信公众号 - K8S中文社区（k8schina）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
