无服务器革命已经停滞不前

几年来，一些人预测无服务器计算将迎来一个新的计算时代，它将在没有操作系统执行应用程序的情况下蓬勃发展。我们被告知此框架将解决大量可伸缩性问题。事实并非如此。

虽然许多人认为无服务器技术是一个新概念，但它的根源可以一直追溯到2006年，以及Zimki PaaS和Google App Engine，这两个产品都探索了无服务器框架。

从有限的编程语言支持到性能问题，无服务器革命停滞不前有四个原因。

无服务器并不是毫无用处的。差得远呢。但是，不应将其视为服务器的直接替代产品。在某些应用程序开发环境中，它可能是一个方便的工具。

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

正如任何在该行业工作的人都知道的那样，正如我们在关于无服务器计算的状态的文章中所指出的那样，这不是真的。尽管有很多文章阐述了无服务器革命的好处，但它并没有实现。事实上，最近的一项研究表明，这场革命可能已经停滞不前。

毫无疑问，为无服务器模型做出的一些承诺已经实现，但并不是所有的承诺都实现了。希望不大。

在本文中，我想看看为什么，尽管无服务器模型在特定的、定义良好的环境中找到了很好的实用性，但这些系统缺乏敏捷性和灵活性似乎仍然是它们更广泛采用的障碍。

在我们讨论无服务器计算的问题之前，让我们先来看看它应该提供什么。无服务器革命的承诺是多重的-有时-非常雄心勃勃。

对于那些新接触这个术语的人，快速定义一下。无服务器计算指的是应用程序(或应用程序的一部分)在通常远程托管的执行环境中按需运行的体系结构。也就是说，在内部托管无服务器系统也是可能的。在过去几年中，构建具有弹性的无服务器系统一直是系统管理员和SaaS公司共同关心的主要问题，因为(据称)此体系结构提供了与“传统”服务器和客户端模型相比的几个关键优势：

无服务器模式不需要用户维护自己的操作系统，甚至不需要构建与特定操作系统兼容的应用程序。相反，开发人员可以生成通用代码，然后将其上传到无服务器框架，并观看其运行。

无服务器框架上使用的资源通常是按分钟(甚至按秒)付费的。这意味着客户端只为他们实际运行代码的时间付费。这与传统的基于云的虚拟机形成了鲜明的对比，在传统的云虚拟机中，您最终往往要为一台大部分时间处于空闲状态的机器买单。

可伸缩性也是一个主要的吸引力。无服务器框架中的资源可以动态分配，这意味着它们能够应对需求的突然激增。

简而言之，这意味着无服务器模型应该提供灵活、廉价、可扩展的解决方案。当这样说的时候，我们没有更早地想出这个主意，这真是令人惊讶。

不过，实际上，我们做到了。让用户只为代码实际运行的时间付费的概念自2006年作为Facebook Zimki PaaS项目的一部分推出以来就一直存在，几乎在同一时间，Google App Engine也提供了非常类似的解决方案。

事实上，我们现在所说的无服务器模式比许多现在被称为云原生技术的技术更古老，它们实现了大致相同的东西。*正如一些人指出的那样，无服务器模式本质上只是存在了几十年的SaaS商业模式的延伸。

同样值得注意的是，无服务器模型也不是FAAS架构，尽管它们之间存在联系。FAAS本质上是无服务器体系结构中以计算为中心的部分，因此可以构成其中的一部分，而不代表整个系统。

那么，为什么现在大肆炒作呢？那么，随着互联网渗透到发展中世界的速度继续快速上升，对计算资源的需求也在同步上升。例如，许多拥有快速增长的电子商务部门的国家，根本没有处理运行这些平台的应用程序的计算基础设施。这就是租用无服务器平台的用武之地。

问题是无服务器模型有..。问题。不要误会我的意思：我并不是说无服务器模式本身就不好，也不是说它们在某些情况下不能为一些公司提供实质性的价值。但这场革命的核心主张--无服务器将迅速取代传统架构--永远不会发生。

大多数无服务器平台只允许您运行用特定语言编写的应用程序。这严重限制了这些系统的灵活性和适应性。

诚然，大多数无服务器平台支持大多数主流语言。AWS Lambda和Azure函数还提供包装器功能，允许您以不受支持的语言运行应用程序和函数，但这通常会以性能为代价。因此，对于大多数组织来说，在大多数情况下，这种限制不会有太大不同。但这里就是问题所在。无服务器模型的优点之一应该是可以更便宜地使用晦涩难懂、不常用的程序，因为您只需为它们执行的时间付费。而晦涩难懂、不常使用的程序通常是用……编写的。晦涩难懂、不常使用的编程语言。

无服务器平台的第二个问题，或者至少是它们目前的实现方式，是很少有平台在操作层面上彼此相似。当涉及到应该编写、部署和管理功能的方式时，几乎没有跨平台的标准化，这意味着将功能从一个特定于供应商的平台迁移到另一个非常耗时。

迁移到无服务器最困难的部分不是计算功能(通常只是代码片段)，而是应用程序与连接的系统(如对象存储、身份管理和队列)纠缠在一起的方式。函数可以移动，但应用程序的其余部分不具有可移植性。这与我们得到的廉价、灵活的平台正好相反。

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

无服务器平台的计算性能可能很难衡量，部分原因是销售这些服务的公司有隐藏这些信息的既得利益。大多数人会声称，运行在远程、无服务器平台上的功能将与在内部服务器上运行的一样快，除非出现一些不可避免的延迟问题。

然而，坊间证据表明情况恰恰相反。以前未在特定平台上运行或在一段时间内未运行的函数需要一些时间进行初始化。这很可能是因为他们的代码已经转移到了一些更难访问的存储介质上--就像他们的性能统计数据一样--如果是这样，大多数无服务器计算供应商都不会透露。

当然，有很多方法可以绕过这一点。其一是针对您的无服务器平台运行的任何云本地语言优化您的功能，但这在一定程度上削弱了这些平台是敏捷的说法。

另一种方法是确保性能关键型程序被安排在频繁的时间间隔运行，以使它们保持新鲜。当然，第二种方法略微与无服务器平台更具成本效益的说法相矛盾，因为您只需为程序运行的时间付费。云提供商已经引入了新的方法来减少冷启动，但许多方法需要将规模扩大到一个模式，这会破坏FAAS的初始价值。

这个冷启动的问题可以通过在内部运行无服务器系统来减少，但这是有成本的，对于资源充足的团队来说仍然是一个利基选择。

最后，也许无服务器架构不会很快取代传统模型的最关键原因是：您(通常)不能在无服务器系统上运行整个应用程序。

或者更确切地说，你可以这样做，但这样做并不划算。您成功的单片应用程序可能不应该变成一系列连接到8个网关、40个队列和12个数据库实例的40多个函数。因此，无服务器非常适合绿地发展。几乎没有现有的应用程序(架构)端口。因此，您可以迁移，但希望从零开始。

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

当然，这不一定是问题。在许多组织中，偶尔使用大量计算资源的能力，而无需支付实现这一目标所需的硬件费用，可能会带来真正和持久的好处。但是，管理应用程序的运行方式(其中一部分在内部服务器上运行，另一部分在无服务器云架构上运行)可能会给这些应用程序的部署带来另一个级别的复杂性。

尽管有这些抱怨，但我并不反对无服务器解决方案本身。我保证。只是开发人员应该意识到--特别是如果他们是第一次探索无服务器模型--这项技术并不能直接替代服务器。取而代之的是，看看我们关于构建无服务器应用程序的提示和资源，并决定如何最好地部署此模型。

伯纳德·布罗德(Bernard Brode)是一名微型机器的产品研究员，他一直对人工智能、网络安全和纳米技术的交叉最终会把我们带到哪里感到好奇。