关键点
- 几年来，我们一直承诺无服务器计算将迎来一个新时代，而无需特定的操作系统即可运行应用程序。有人告诉我们，这种结构将解决许多可伸缩性问题。实际上，一切都不同。
- 尽管许多人将无服务器技术视为一个新概念，但其根源可以追溯到2006年，当时Zimki PaaS和Google App Engine都采用了无服务器架构。
- 无服务器革命的停滞有四个原因，从对编程语言的有限支持到性能问题。
- 无服务器计算并非没有用。一点也不。但是，不应将它们视为服务器的直接替代。对于某些应用程序，它们可以成为方便的工具。
服务器死了，服务器万岁！
这是无服务器革命的专家们的战斗口号。快速浏览一下过去几年的行业媒体，您可以轻松得出结论，传统服务器模型已经失效，并且在几年之内，我们所有人都将使用无服务器架构。
业内人士都知道，并且正如我们在有关无服务器计算的状态的文章中所指出的，情况并非如此。尽管有许多关于无服务器革命的优点的文章，但从未实现。实际上，最近的研究表明，这场革命可能陷入僵局。
无服务器模型的某些承诺无疑已经实现，但并非全部。不是每个人。
在本文中，我想考虑这种情况的原因。尽管缺乏服务器模式的灵活性在特定的，明确定义的环境中仍然有用，但为何缺乏服务器无模型的灵活性仍是其广泛采用的障碍。
无服务器计算的倡导者承诺
在探讨无服务器计算问题之前，让我们看看它们必须提供什么。无服务器革命的希望是无数的，有时甚至是雄心勃勃的。
对于那些不熟悉该术语的人，这里有一个快速定义。无服务器计算定义了一种体系结构，其中应用程序（或应用程序的一部分）在通常是远程托管的运行时环境中按需执行。另外，可以托管无服务器系统。在过去的几年中，构建有弹性的无服务器系统一直是系统管理员和SaaS公司的头等大事，因为（据称）该体系结构具有优于“传统”客户端/服务器模型的几个关键优势：
- , , . , .
- ( ). , , . VM, , .
- . , .
简而言之，无服务器模型提供了灵活，低成本，可扩展的解决方案。令人惊讶的是我们之前没有想到这个想法。
这真的是个新主意吗？
实际上，这个想法并不新鲜。自从代码于2006年作为Zimki PaaS的一部分引入以来，允许用户只为代码实际运行的时间付费的概念就已经存在，并且大约在同一时间，Google App Engine提供了非常相似的解决方案。
实际上，我们现在所说的“无服务器”模型比现在提供了相同功能的许多“原生云”技术要古老。如前所述，无服务器模型本质上只是SaaS业务模型的扩展，而SaaS业务模型已经存在了数十年。
还应该认识到，尽管无服务器模型不是FaaS架构，但是两者之间存在联系。FaaS本质上是无服务器体系结构中面向计算的部分，但并不代表整个系统。
那么，大惊小怪的是什么？很好，随着Internet在发展中国家的普及速度持续飙升，对计算资源的需求也在增长。例如，许多电子商务行业快速增长的国家根本就没有这些平台上应用程序的计算基础架构。这是付费无服务器平台的用武之地。
无服务器模型问题
问题在于，无服务器模型存在……问题。不要误会我的意思：我并不是说它们本身很糟糕，或者在某些情况下它们不能为某些公司提供重大价值。但是，“革命”的主要主张-无服务器架构将迅速取代传统架构-从未实现。
这就是为什么。
对编程语言的支持有限
大多数无服务器平台仅允许运行以特定语言编写的应用程序。这严重限制了这些系统的灵活性和适应性。
无服务器平台被认为支持大多数主要语言。AWS Lambda和Azure Functions还提供了用于以不受支持的语言运行应用程序和功能的包装，尽管这通常会带来性能成本。因此，对于大多数组织而言，此限制通常并不重要。但是，这就是事情。假定无服务器模型的优点之一是可以便宜地使用鲜为人知，很少使用的程序，因为您只需为执行时间付费。鲜为人知，很少使用的程序通常是用……鲜为人知，很少使用的编程语言编写的。
这破坏了无服务器模型的主要优势之一。
供应商绑定
无服务器平台（或者至少是当前实现方式）的第二个问题是，它们在操作级别上通常看起来并不相同。在编写功能，部署和管理方面几乎没有标准化。这意味着将功能从一个平台迁移到另一个平台非常耗时。
转向无服务器模型的最困难部分不是计算功能，通常只是代码，而是应用程序如何与连接的系统（如对象存储，身份管理和队列）相关联。功能可以移动，但应用程序的其余部分不能移动。这与承诺的低成本和灵活平台完全相反。
一些人认为无服务器模型是新的，并且没有时间标准化它们的工作方式。但是，正如我上面提到的那样，它们并不是那么新，而且许多其他云技术（例如容器）已经通过开发和广泛采用良好标准而变得更加可用。
性能
无服务器平台的计算性能很难衡量，部分原因是供应商倾向于将信息保密。大多数人认为，在远程，无服务器平台上的功能与内部服务器上的功能一样快，除了一些不可避免的延迟问题。
但是，一些事实表明并非如此。先前未在特定平台上运行或一段时间未运行的功能需要花费一些时间来初始化。这可能是由于他们的代码已移植到一些访问性较差的存储介质上，尽管-与基准测试一样-大多数供应商不会告诉您有关数据传输的事实。
当然，有几种方法可以解决此问题。一种是针对无服务器平台运行的任何云语言优化功能，但这在一定程度上破坏了这些平台“灵活”的说法。
另一种方法是确保对性能至关重要的程序定期运行以保持它们的最新状态。当然，第二种方法与无服务器平台更具成本效益的观点相矛盾，因为您只需为程序的运行时间付费。云提供商已经引入了减少冷启动的新方法，但是许多方法都需要“按比例缩放”，这破坏了FaaS的原始价值。
冷启动问题可以通过内部运行无服务器系统来部分解决，但这是有代价的，对于资源丰富的团队而言仍然是一个小众选择。
您无法运行整个应用程序
最后，也许最重要的原因为何无服务器架构很快就不会取代传统模型：它们（通常）无法运行整个应用程序。
更确切地说，它不具有成本效益。您成功的独石可能不应该变成由八个网关，四十个队列和一打数据库实例链接的一打四打功能集合。因此，无服务器更适合于新开发。几乎没有现有的应用程序（架构）可以迁移。您可以迁移，但必须从头开始。
这意味着在大多数情况下，无服务器平台用于补充后端服务器以完成计算密集型任务。这与云计算的其他两种形式（容器和虚拟机）非常不同，后者提供了执行远程计算的整体方法。这说明了从微服务迁移到无服务器系统的挑战之一。
当然，这并不总是一个问题。无需购买自己的硬件即可定期使用大量计算资源的能力可以为许多组织带来真正而持久的收益。但是，如果某些应用程序在内部服务器上，而另一些应用程序在无服务器的云体系结构上，那么管理将达到新的高度复杂性。
革命万岁？
尽管有所有这些抱怨，但我并不反对无服务器解决方案本身。老实说 只是开发人员需要了解-尤其是如果他们是第一次探索无服务器模型时-该技术不是服务器的直接替代。相反，请查看有关构建无服务器应用程序的技巧和资源，并了解如何最好地应用此模型。