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