要点

• 几年来，我们一直被承诺无服务器计算将迎来一个无需特定操作系统来运行应用程序的新时代。 我们被告知这种结构将解决许多可扩展性问题。 事实上，一切都不一样了。
• 虽然许多人将无服务器视为一个新想法，但其根源可以追溯到 2006 年 Zimki PaaS 和 Google App Engine 的出现，这两者都使用无服务器架构。
• 无服务器革命停滞不前有四个原因，从有限的编程语言支持到性能问题。
• 无服务器计算并非毫无用处。 一点也不。 但是，不应将它们视为服务器的直接替代品。 对于某些应用程序，它们可以是一个方便的工具。

服务器死了，服务器万岁！

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

正如业内人士所知，正如我们在有关的文章中也指出的那样 无服务器计算的现状，这是错误的。 尽管有很多关于其优点的文章 无服务器革命，它从未发生过。 实际上， 最近的研究表明这场革命可能已经走进了死胡同。

无服务器模型的一些承诺确实已经实现，但并非全部。 不是每个人。

在这篇文章中，我想看看造成这种情况的原因。 为什么无服务器模型缺乏灵活性仍然是其广泛采用的障碍，尽管它们在特定的、明确定义的环境中仍然有用。

无服务器计算专家的承诺

在我们讨论无服务器计算的挑战之前，让我们先看看它应该提供什么。 无服务器革命的承诺 人数众多，而且有时非常雄心勃勃。

对于那些不熟悉该术语的人，这里有一个快速定义。 无服务器计算定义了一种架构，其中应用程序（或应用程序的一部分）在通常远程托管的运行时环境中按需运行。 此外，无服务器系统可以在家中托管。 在过去的几年里，构建弹性无服务器系统一直是系统管理员和 SaaS 公司的主要关注点，因为（据称）这种架构比“传统”客户端-服务器模型提供了几个关键优势：

1. 无服务器模型不需要用户维护自己的操作系统，甚至不需要创建与特定操作系统兼容的应用程序。 相反，开发人员创建共享代码，将其上传到无服务器平台，然后观察其运行。
2. 无服务器框架中的资源通常按分钟（甚至秒）计费。 这意味着客户只需为实际运行代码的时间付费。 这与传统的云虚拟机相比毫不逊色，传统的云虚拟机大部分时间都是闲置的，但你必须为此付费。
3. 可扩展性问题也得到了解决。 Serverless框架中的资源是动态分配的，因此系统可以轻松应对突然激增的需求。

简而言之，无服务器模型提供了灵活、低成本、可扩展的解决方案。 令人惊讶的是我们没有更早地想到这个想法。

这真的是一个新想法吗？

事实上，这个想法并不新鲜。 允许用户只为代码实际运行的时间付费的概念自从由 Zimki PaaS 2006 年，大约在同一时间，Google App Engine 提供了一个非常相似的解决方案。

事实上，我们现在所说的“无服务器”模型比许多现在称为“云原生”的技术更古老，这些技术提供了大致相同的功能。 如前所述，无服务器模型本质上只是已经存在了数十年的 SaaS 业务模型的延伸。

还值得认识到的是，无服务器不是 FaaS 架构，尽管两者之间存在联系。 FaaS 本质上是无服务器架构中以计算为中心的部分，但它并不代表整个系统。

那么有什么大惊小怪的呢？ 那么，随着发展中国家的互联网普及率不断飙升，对计算资源的需求也同时增加。 例如，许多电子商务行业快速增长的国家根本不具备用于这些平台上的应用程序的计算基础设施。 这就是付费无服务器平台的用武之地。

无服务器模型的问题

问题是无服务器模型存在......问题。 不要误会我的意思：我并不是说它们本身不好或者在某些情况下不能为某些公司提供重大价值。 但“革命”的主要主张——无服务器架构将迅速取代传统架构——从未实现。

这就是为什么。

对编程语言的支持有限

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

无服务器平台被认为支持大多数主要语言。 AWS Lambda 和 Azure Functions 还提供了一个包装器，用于以不受支持的语言运行应用程序和函数，尽管这通常会带来性能成本。 因此对于大多数组织来说，这种限制通常不是什么大问题。 但事情是这样的。 无服务器模型的好处之一应该是鲜为人知、很少使用的程序可以更便宜地使用，因为您只需为它们运行的​​时间付费。 鲜为人知、很少使用的程序通常是用...鲜为人知、很少使用的编程语言编写的。

这破坏了无服务器模型的主要优势之一。

供应商绑定

无服务器平台的第二个问题，或者至少是它们目前的实现方式，是它们在操作层面通常彼此不相似。 在编写功能、部署和管理方面实际上没有标准化。 这意味着将功能从一个平台迁移到另一个平台非常耗时。

迁移到无服务器模型最困难的部分不是计算功能（通常只是代码片段），而是应用程序如何与对象存储、身份管理和队列等连接系统进行通信。 功能可以移动，但应用程序的其余部分不能移动。 这与承诺的廉价且灵活的平台恰恰相反。

一些人认为无服务器模型是新的，还没有时间标准化它们的工作方式。 但正如我上面提到的，它们并不是那么新鲜，并且由于良好标准的开发和广泛采用，许多其他云技术（例如容器）已经变得更加可用。

Производительность

无服务器平台的计算性能难以衡量，部分原因是供应商倾向于将信息保密。 大多数人认为，远程无服务器平台上的功能与内部服务器上的功能运行速度一样快，除了一些不可避免的延迟问题。

然而，个别事实表明事实恰恰相反。 以前未在特定平台上运行或一段时间未运行的功能将需要一些时间来初始化。 这可能是由于他们的代码已被移植到一些难以访问的存储介质，尽管与基准测试一样，大多数供应商不会告诉您有关数据迁移的信息。

当然，有几种方法可以解决这个问题。 一是针对无服务器平台运行的任何云语言优化功能，但这在某种程度上削弱了这些平台“敏捷”的主张。

另一种方法是确保定期运行对生产力至关重要的程序以保持新鲜感。 当然，第二种方法与无服务器平台更具成本效益的说法有点矛盾，因为您只需为程序运行的时间付费。 云提供商推出了减少冷启动的新方法，但其中许多方法需要“规模化到一”，这破坏了 FaaS 的原始价值。

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

您无法运行整个应用程序

最后，也许无服务器架构不会很快取代传统模型的最重要原因：它们（通常）无法运行整个应用程序。

更准确地说，从成本角度来看这是不切实际的。 您成功的整体应用程序可能不应该变成由八个网关、四十个队列和十几个数据库实例连接的四打功能的集合。 因此，无服务器更适合新的发展。 几乎没有现有的应用程序（架构）可以迁移。 您可以迁移，但必须从头开始。

这意味着在绝大多数情况下，无服务器平台被用作后端服务器的补充来执行计算密集型任务。 这使得它们与其他两种形式的云技术（容器和虚拟机）非常不同，后者提供了执行远程计算的整体方法。 这说明了从微服务转向无服务器的挑战之一。

当然，这并不总是一个问题。 无需购买自己的硬件即可定期利用大量计算资源的能力可以为许多组织带来真正、持久的好处。 但是，当某些应用程序驻留在内部服务器上，而其他应用程序驻留在无服务器云架构上时，管理就会变得更加复杂。

革命万岁？

尽管有这些抱怨，我并不反对无服务器解决方案本身。 诚实地。 开发人员只需要了解（尤其是如果他们是第一次探索无服务器）该技术并不能直接替代服务器。 相反，请查看我们的提示和资源 创建无服务器应用程序 并决定如何最好地应用该模型。

来源： habr.com