几年来，有人预测无服务器计算将迎来一个新的计算时代，我们被告知该框架将解决许多可扩展性问题，但事实并非如此。虽然许多人将无服务器技术视为一个新想法，但它的根源可以追溯到2006年，当时ZimkiPaaS和GoogleAppEngine都在探索无服务器框架。在过去几年中，构建有弹性的无服务器系统一直是系统管理员和SaaS公司关注的主要问题，因为（据推测）该架构比“传统”服务器和客户端模型具有多项优势。关键优势：无服务器模型不需要用户维护自己的操作系统，甚至不需要构建与特定操作系统兼容的应用程序。相反，开发人员可以生成通用代码，将其上传到无服务器框架，然后观察它运行。无服务器框架上使用的资源通常按分钟（甚至秒）付费。这意味着客户只需为他们实际运行代码的时间付费。这与传统的基于云的虚拟机形成鲜明对比。可扩展性也是一个很大的吸引力。无服务器框架中的资源可以动态分配，这意味着它们能够处理突然的需求高峰。简而言之，这意味着无服务器模型应该提供灵活、廉价和可扩展的解决方案。但上述架构一直存在四大缺陷：1.有限的编程语言——大多数无服务器平台只允许你运行以特定语言编写的应用程序。这严重限制了这些系统的敏捷性和适应性。诚然，大多数无服务器平台都支持大多数主要语言。AWSLambda和AzureFunctions还提供包装函数，允许您以不受支持的语言运行应用程序和函数，尽管这通常会以性能成本为代价。因此，对于大多数组织而言，此限制在大多数情况下不会产生太大影响。这破坏了无服务器模型的关键优势之一。2.供应商锁定——无服务器平台的第二个问题（或者至少它们目前的实现方式）是很少有平台在操作层面上彼此相似。在功能的编写、部署和管理方式方面跨平台几乎没有标准化，这意味着将功能从一个供应商特定平台迁移到另一个供应商特定平台非常耗时。迁移到无服务器最困难的部分不是计算功能（通常只是代码片段），而是应用程序与连接系统（如对象存储、身份管理和队列）纠缠在一起的方式。功能可以移动，但应用程序的其余部分的可移植性较差。这与我们承诺的廉价、灵活的平台背道而驰。我怀疑有些人会争辩说无服务器模型是新的，还没有时间标准化它们的工作方式。然而，正如我在上面指出的那样，它们并不是那么新，并且通过基于社区的强大标准的开发和广泛采用，许多其他云原生技术（如容器）变得更加可用。3.性能难以衡量——无服务器平台上的计算性能可能难以衡量，部分原因是销售这些服务的公司有隐藏这些信息的既得利益。大多数人会声称在无服务器远程平台上运行的功能将与在内部服务器上运行一样快，除非存在一些不可避免的延迟问题。然而，轶事证据表明并非如此。之前未在特定平台上运行或有一段时间未运行的功能需要一些时间来初始化。这可能是因为他们的代码被转移到一些不易访问的存储介质上，尽管像他们的性能统计一样，大多数无服务器计算供应商不会在这种情况下泄漏。当然，有很多方法可以解决这个问题。一种方法是为无服务器平台运行的任何云原生语言优化功能，但这在某种程度上削弱了这些平台“敏捷”的说法。另一种方法是确保性能关键程序被安排为频繁运行，以便它们保持“新鲜”。当然，第二种方法与无服务器平台更具成本效益的说法有些矛盾，因为您只需为程序运行的时间付费。云提供商已经引入了减少冷启动的新方法，但许多都需要一种破坏FaaS初始价值的“规模对一”模型。这种“冷启动”问题可以通过在内部运行无服务器系统来减少，但这有其自身的成本，并且对于资源丰富的团队来说仍然是一个利基选择。4.无法运行整个应用程序——最后，也许是无服务器架构不会很快取代传统模型的最关键原因：（通常）你不能在无服务器系统上运行整个应用程序。或者更确切地说，你可以，但这样做不划算。一个成功的单体应用程序可能不应该是一个由四打功能连接到八个网关、四十个队列和十几个数据库实例的家庭。因此，serverless适合未开发的领域。很少有现有的应用程序（架构）被移植过来。因此您可以迁移，但希望从头开始。这意味着，在大多数情况下，无服务器平台将用作内部服务器的附件，以执行需要大量计算资源的任务。这使得它们确实与其他两种形式的云原生技术（容器和虚拟机）截然不同，这两种技术都提供了执行远程计算的整体方法。这说明了从微服务过渡到无服务器的困难之一。当然，这不一定是个问题。在许多组织中，偶尔使用大量计算资源而无需支付内部实现此功能所需的硬件的能力可以带来真正和持久的好处。但是，管理应用程序的运行方式（其中一些在内部服务器上，另一些在无服务器云架构上）可能会进一步增加这些应用程序部署的复杂性。
