Serverless 的承诺都兑现了吗?

Serverless 的承诺都兑现了吗?
文章图片
2009年 , 加州大学伯克利分校发布了一篇论文《TheBerkeleyViewonCloudComputing》 , 正确预测了接下来十年的云计算演进和普及 。 2019年 , 伯克利又发布了一篇有着相同命名风格的论文《ABerkeleyViewonServerlessComputing》 , 再次预言未来“无服务器计算将会发展成为未来云计算的主要形式” 。 无服务器被寄予厚望 , 但同时也存在一些争议 。 如今 , 距离2014年AmazonLambda首次发布已有七年时间 , 我们回头去看 , 当初那些无服务器的承诺都能兑现了吗?
无服务器的承诺和争议
“无服务器”术语最早出现在2012年左右的一篇文章里 , 作者KenFromm对它的解释是:
“无服务器”一词并不意味着不再涉及服务器 , 它只是意味着开发人员不再需要考虑那么多的物理容量或其他基础设施资源管理责任 。 通过消除后端基础设施的复杂性 , 无服务器让开发人员将注意力从服务器级别转移到任务级别 。
虽然不少技术先知认为无服务器架构是“一项重大创新并将很快流行起来” , 但这个概念在提出当时并没有得到很好的反响 。
真正让无服务器得到广泛关注的事件是亚马逊云科技于2014年推出AmazonLambda服务 。 之后 , 随着谷歌和微软等企业的服务进入市场 , “无服务器”才逐渐成为行业“热词” 。
相较于“传统服务” , 无服务器计算的优势主要有几点:
在无服务器平台上 , 无需用户自身去维护操作系统 。 开发人员只需要编写云函数 , 选择触发云函数运行的事件就可以完成工作 。 例如加载一个镜像到云存储中 , 或者向数据库添加一个很小的图片 , 让无服务器系统本身来处理其他所有系统管理的操作 , 如选择实例、部署、容错、监控、日志、安全补丁等等 。 更好的自动扩缩容方式 , 理论上能应对突发的从“零”到“无穷大”的需求峰值 。 有关扩展的决定由云提供商按需提供 , 开发人员不再需要编写自动扩展策略或定义机器级别资源(CPU、内存等)的使用规则 。 传统云计算按照预留的资源收费 , 而无服务器按照函数执行时间收费 。 这也意味着更加细粒度的管理方式 。 在无服务器框架上使用资源只需为实际运行时间付费 。 这与传统云计算收费方式形成了鲜明对比 , 后者用户需要为有闲置时间的计算机付费 。作为云计算的下一个迭代 , 无服务器计算让开发者可以更关注于构建产品中的应用 , 而不需要管理和维护底层堆栈 , 且比传统云计算更为便宜 , 因此无服务器被誉为“开发新应用最快速的方式 , 同时也是总成本最低的方式” 。
“伯克利观点”甚至认为 , 无服务器计算提供了一个接口 , 极大地简化了云编程 , 这种转变类似于“从汇编语言迁移到高级编程语言” 。
从诞生开始 , “无服务器”就被寄予了厚望 , 但在发展过程中也免不了会存在争议 , 之前涉及到的一些问题有:
编程语言受限 。 大多数无服务器平台仅支持运行特定语言编写的应用 。 供应商锁定风险 。 在“函数”的编写、部署和管理方式上 , 几乎不存在跨平台的标准 。 这意味着将“函数”从一个特定于供应商的平台迁移到另一个平台非常耗时费劲 。 性能问题如冷启动 。 如果某个“函数”之前未在特定平台上运行过 , 或是在一段时间内未运行 , 那么就需要耗费一些时间做初始化 。2019年被认为是无服务器有重大发展的一年 。 在这一年的年底 , 亚马逊云科技发布了AmazonLambda的“预置并发(ProvisionedConcurrency)”功能 , 它允许亚马逊云科技无服务器计算用户使其函数保持“已初始化并准备好在两位数毫秒内响应”的状态 , 这意味着“冷启动”问题成为过去 , 行业达到一个成熟点 。