无服务器技术可以通过公共云提供商的服务更容易被企业访问，但只是因为它是可用的，并不意味着企业就应该使用它。
像许多热门的IT趋势一样，无服务器计算及其优势经常被过度简化。因此，有些组织甚至在没有强大的理由的情况下追赶无服务器的潮流。
无服务器部署需要考虑很多因素，但是有三个特定的警告信号表明并不适合某些企业。
1.应用程序无法更改
如果企业打算部署第三方软件或传统应用程序，却无法或不会改变，企业将面临无服务器的主要问题。来自***云提供商的无服务器产品(如AWS的Lambda，Azure Functions和Google Cloud Functions)还是相当新颖的，但很多旧版本的软件并没有考虑到这些。
可以说，无服务器计算是从社交网络应用程序中派生出来的，其中最引人注目的是Twitter，它遵循事件处理模型。但是如今的大多数商业应用程序并不是为事件处理而构建的，这并不意味着它们不能这样工作，而是需要改变这些应用程序如何分解成组件，以及这些组件的逻辑。
一些用户发现，近三分之二的无服务器目标应用程序是无法更改的，无论是因为第三方供应商拥有它们还是需要大量时间和费用。如果企业使用第三方软件，需要从软件供应商那里寻求应用程序可以在无服务器体系结构上运行的合同承诺。
2.企业的应用程序总是运行
当需要应用程序功能时，企业仅需要支付无服务器计算成本，虽然这可以节约成本，但也会导致经常运行的应用程序的成本过高。一个理想的无服务器应用程序已经准备好在几毫秒内运行，但不能经常被调用。一个持续运行的应用程序将在大多数时间内承担费用，这些费用将远高于在云端运行虚拟机或容器的成本。
通常企业很难知道应用程序是需要运行还是只是准备运行。需要运行的一个很好的例子是在繁忙的零售商店中支持信用终端的应用程序。这个应用程序被称为每一次购买，这使得它适合更加传统的基础设施即服务平台。准备运行的一个例子是监视由温度波动触发的仓库中的环境传感器的应用。这种类型的应用程序需要随时运行，但不会经常运行，这使得它成为无服务器计算的理想选择。
3.应用程序是有状态的
由于无服务器应用程序按需加载和运行，因此在使用的应用程序之间不能保存结果。这种保存操作被称为有状态或场景。如果企业的应用程序本质上是有状态的 - 就像提供某些更新或支持多步对话的任何业务应用程序一样，将会远离无服务器。
亚马逊公司和微软公司将无服务器计算描述为functional或lambda处理。这是指一种特定的编程技术，它可以避免在应用程序或应用程序组件中从一个激活到另一个激活保存任何东西。functional或lambda逻辑始终是无状态的，这使得应用程序组件的任何副本都可以处理事件。
谷歌公司将无服务器称为微服务计算。微服务也应该是无状态的，部分原因是应用程序可能共享相同的逻辑，这使得保存场景可能会在不知情的情况下传递给另一个应用程序或用户是危险的。
企业可能需要重写部分或全部应用程序来解决这个无状态问题。即使不需要重写，只需要更改应用程序设计的一部分，就可以让开发人员知道如何处理状态、场景、lambda编程，以及微服务。
