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