为何 Serverless 革命停滞不前（译）

原文：Bernard Brode - 2020.10.12

主要观点

• 近几年来，有人预测 Serverless 计算将带来一种全新的计算时代，这种时代的应用程序无需操作系统即可运行。我们被告知这种框架将解决许多可扩展性问题。然而，现实并非如此。
• 尽管许多人将 Serverless 技术视为一个新概念，但其根源可以追溯到 2006 年，Zimki PaaS 和 Google App Engine 都探索了 Serverless 框架。
• 从有限的编程语言支持到性能问题，有四个原因导致 Serverless 革命停滞不前。
• Serverless 并非毫无用处。恰恰相反，它不应被视为直接替代 servers 的解决方案。在某些应用程序开发环境中，它可以是一个非常方便的工具。

server 已死，server 万岁！

这就是 Serverless 革命的战斗口号。即使是快速浏览一下过去几年的行业新闻，也很容易得出这样的结论：传统服务器模型已经过时，几年内我们都将运行 Serverless 架构。

然而，任何在该行业工作的人都知道，正如我们在关于Serverless 计算现状的文章中所指出的，事实并非如此。尽管许多文章赞扬Serverless 革命的优点，但它尚未实现。事实上，最近的研究显示这场革命可能已经陷入了停滞。

毫无疑问，Serverless 模型的一些承诺已经实现，但并非全部，远没有达到预期。

在本文中，我想探讨为什么，尽管 Serverless 模型在特定的、明确定义的情况下发挥了很大的作用，但这些系统敏捷性和灵活性的缺乏，仍然是阻碍其更广泛采用的障碍。

Serverless 计算的承诺

在讨论 Serverless 计算的问题之前，让我们先看看它应该提供什么。Serverless 革命的承诺多种多样，有时甚至非常雄心勃勃。

对于初次接触这个术语的人来说，这里有一个简单的定义：Serverless 计算指的是一种架构，其中应用程序（或应用程序的一部分）在通常远程托管的执行环境中按需运行。话虽如此，也可以在内部托管 Serverless 系统。在过去的几年中，构建弹性的 Serverless 系统已经成为系统管理员和 SaaS 公司的主要关注点，因为（据称）这种架构提供了几个关键优势，超越了“传统”的服务器和客户端模型：

1. Serverless 模型不需要用户维护自己的操作系统，甚至不需要构建与特定操作系统兼容的应用程序。相反，开发人员可以生成通用代码，然后将其上传到 Serverless 框架，并观察其运行。
2. 在 Serverless 框架上使用的资源通常按分钟（甚至按秒）付费，意味着客户只为实际运行代码的时间付费。这与传统的基于云的虚拟机形成鲜明对比，通常你最终会为大部分时间空闲的机器付费。
3. 可扩展性也是一个主要的吸引点。Serverless 框架中的资源可以动态分配，这意味着它们能够应对突增的需求。

简而言之，这意味着 Serverless 模型应该提供灵活、便宜、可扩展的解决方案。这么说来，令人惊讶的是我们没有更早地提出这个想法。

这是一个新的想法吗？

事实上，我们确实做到了。让用户只为代码实际运行时间付费的概念自 2006 年作为 Zimki PaaS 的一部分引入，Google App Engine 大约在同一时间提供了非常相似的解决方案。

实际上，现在称之为 “Serverless” 的模型比许多现在被称为 “云原生” 的技术更老，这些技术实现了大致相同的目标。正如一些人注意到的，Serverless 模型本质上只是一个已经存在了数十年的 SaaS 业务模型的延伸。

值得认识到的是，Serverless 模型也并非等同于 FaaS（函数即服务）架构，尽管它们之间存在联系。本质上，FaaS 是 Serverless 架构中以计算为中心的部分，因此可以作为 Serverless 的一部分，但并不能代表整个系统。

那么为什么现在这么多炒作呢？好吧，随着internet 在发展中世界的渗透率持续快速上升，对计算资源的需求也在同步增长。例如，许多电子商务行业迅速发展的国家，根本没有处理运行这些平台应用程序的计算基础设施。这就是 Serverless 平台的用武之地。

Serverless 的问题

问题在于，Serverless 模型存在一些问题。别误会我的意思：并不是在说 Serverless 模型本身就有问题，或者在某些情况下它们对某些公司没有提供实质性的价值。但是 “革命” 的核心主张 —— Serverless 将迅速取代传统架构 —— 这一点永远不会发生。

原因如下。

编程语言的支持有限

大多数的 Serverless 平台只允许运行用特定语言编写的应用，这严重限制了这些系统的灵活性和适应性。

诚然，一般 Serverless 平台支持大多数主流语言。AWS Lambda 和 Azure Functions 还提供了包装器功能，允许你运行在非支持语言中的应用和函数，尽管这常常伴随着性能代价。所以对于大多数组织来说，大部分时间，这个限制并不会带来太大的影响。但问题在于，Serverless 模型的优点之一应该是可以更便宜地利用那些罕见、不常用的程序，因为你只需为它们执行的时间付费。而这些罕见、不常用的程序往往是用…罕见、不常用的编程语言编写的。

这削弱了 Serverless 模型的一个关键优势。

供应商锁定

Serverless 平台的第二个问题，或者至少是它们目前实现方式的问题，是很少有平台在操作层面上彼此相似。在函数应该如何编写、部署和管理的方式上，各个平台之间几乎没有标准化，这意味着将函数从一个特定供应商的平台迁移到另一个平台非常耗时。

迁移到 Serverless 的最难部分并不是计算函数 —— 它们通常只是代码片段 —— 而是应用程序与对象存储、身份管理和队列等连接系统的交织方式。函数可以移动，但应用程序的其余部分并不那么便携。这与我们被承诺的便宜、灵活的平台恰恰相反。

我猜想，有些人会争辩说，Serverless 模型是新的，还没有时间去标准化它们的工作方式。但正如我上面指出的，它们并不是那么新，而且像容器这样的其他许多云原生技术已经通过开发和广泛采用强大的、基于社区的标准变得更加易用。

性能

Serverless 平台的计算性能可能难以衡量，部分原因是出售这些服务的公司有利益使这些信息保密。大多数公司会声称，在 Serverless 平台上运行的函数将与在内部服务器上运行一样快，除了一些无法避免的延迟问题。

然而，一些实证证据却显示出相反的情况。在特定平台上尚未运行过，或者一段时间内没有运行过的函数，需要一些时间来初始化。这可能是因为它们的代码已经被转移到一些不易访问的存储介质上，但就像他们的性能统计一样，大多数 Serverless 计算供应商不会透露是否是这种情况。

当然，有很多方法可以解决这个问题。一种是优化你的函数，以适应所在 Serverless 平台运行的任何云原生语言，但这在某种程度上削弱了这些平台是"敏捷的"说法。

另一种方法是确保性能关键的程序定期运行，以保持它们的"新鲜度"。当然，第二种方法稍微与 Serverless 平台更具成本效益的说法相矛盾，因为你只需为程序运行的时间付费。云供应商已经引入了新的方法来减少冷启动，但许多方法需要一个"缩放到一"的模型，这削弱了 FaaS 的初始价值。

这个"冷启动"的问题可以通过在内部运行 Serverless 系统来减少，但这会带来一定的成本，并且对于资源充足的团队来说，仍然是一个小众选择。

不能运行整个应用程序

最后，也许是最关键的原因，为什么 Serverless 架构不会在短期内取代传统模型：你（通常）不能在 Serverless 系统上运行整个应用程序。

或者更确切地说，可以这么做，但不具有成本效益。你原有的单体应用程序可能不应该变成连接到八个网关、四十个队列和十二个数据库实例的四十多个函数。因此，Serverless 更适合全新的项目，几乎没有现有的应用程序（架构）可以移植过来。所以你可以迁移，但期望从零开始。

这意味着，在绝大多数情况下，Serverless 平台被用作内部服务器的辅助工具，执行需要大量计算资源的任务。这使得它们与其他两种形式的云原生技术（容器和虚拟机）有很大的不同，它们都提供了执行远程计算的整体方式。这说明了从微服务过渡到 Serverless 的困难之一。

当然，这不一定是个问题。在许多组织中，偶尔能够利用巨大的计算资源，而不用支付在内部实现这一点所需的硬件费用，可能会带来实际和持久的利益。然而，管理应用程序的运行方式，其中一部分在内部服务器上运行，而其他部分在 Serverless 云架构上运行，可能会给这些应用程序的部署带来另一层复杂性。

长久革命？

尽管有所有这些抱怨，我并不反对 Serverless 解决方案本身。只是开发者应该意识到 —— 特别是如果他们是第一次探索 Serverless 模型 —— 这项技术并不是直接替代服务器的解决方案。相反，看看我们的建议和资源，了解如何构建 Serverless 应用程序，并决定最好的部署方式。

关于作者

Bernard Brode 是 Microscopic Machines 的产品研究员，他对 AI、网络安全和纳米技术的交叉最终如何引领我们的未来充满了深深的好奇心。