如果没有人提到无服务器计算，这些天很难与DevOps进行对话。AWS Lambda和Azure Functions等无服务器计算平台与Docker和Kubernetes正在为部署应用程序提供有价值的新方法。
虽然无服务器提供了许多重要的好处，但它并不能解决所有类型的应用程序部署问题。聪明的开发人员知道，最新、最好的技术并不总是最适合各种类型的工作负载。
所以，当你应该在什么情况下不使用无服务器？我们将在本文中讨论。
什么是无服务器？
首先，简要说明无服务器计算的含义。
简而言之，无服务器是一种应用程序部署解决方案，无需为应用程序维护完整的主机环境。DevOps团队可以简单地将各个功能上传到无服务器环境并按需执行，而无需设置虚拟机（甚至是Docker容器）来执行代码。
自2000年代中期以来，这种解决方案已经存在，但直到2014年，随着AWS Lambda的首次亮相，它才开始流行并广为人知。（从这个意义上讲，无服务器类似于容器;），容器或类似容器的技术已经以chroot，FreeBSD jails和LXC的形式存在了几十年，但只有在2013年发布Docker时，每个人都开始讨论容器。
无服务器计算提供了一些有用的好处
- 代码几乎可以立即执行。您不必等待虚拟机或容器启动。
- 在大多数无服务器平台上，您只需为代码运行的时间付费。通过这种方式，无服务器成本低于必须为不断运行的虚拟服务器付费，即使它所托管的应用程序并未经常使用。
- 无服务器代码可以大规模扩展。因为您无需在启动无服务器功能之前等待环境启动，或者在工作负载增大时配置更多虚拟服务器，因此无需延迟即可使用无服务器代码处理的请求数量实际上是无限制的。
不使用无服务器的原因
虽然无服务器计算对于某些用例可能是有利的，但有很多充分的理由考虑不使用它。
1.你的负载量是不变的无服务器是部署体积快速波动的工作负载的理想选择。如果你的工作负载相对稳定，那么就像一个网络应用程序，其流量不会随着时间的推移而变化，你将从无服务器上获得很少的收益。
因此，在将代码移动到无服务器平台之前，仅仅因为每个人都在谈论它，考虑无服务器的大规模可扩展性和按需执行功能是否真的会帮助您。
2.你害怕供应商锁定
大多数无服务器平台都与特定的云计算供应商联系在一起。即使那些被设计为纯粹的开源和开源的设备，如OpenWhisk，也是彼此不兼容的。
当社区标准围绕无服务器计算出现时，可能会出现这样的一天，并且他们将为无服务器做OCI为容器做的事情。但那一天还没来。
虽然可以将无服务器工作负载从一个平台迁移到另一个平台，但这样做需要大量的手动工作。您有一天不能使用Lambda，而是在下一次使用Azure功能。
这意味着，如果您今天使用无服务器，您应该期望在可预见的未来使用您使用的任何特定平台。对于不喜欢锁定的组织来说，这可能是避开无服务器平台的一个令人信服的理由。
3.您需要高级监控
无服务器作为一种广泛使用的部署解决方案的相对新颖性也意味着用于无服务器功能的监视和安全工具的生态系统仍然不成熟。
一些供应商工具声称能够支持无服务器监控，并且可能会随着时间的推移出现更多。但就目前而言，功能集仍然相对基础。
如果您需要针对无服务器环境的强大监控解决方案，现在可能不是开始使用无服务器的时候了。
4.你有长期的功能
无服务器解决方案（如Lambda）的主要限制之一是每个无服务器代码实例可以运行有限的时间（在Lambda的情况下为5分钟）。
如果大多数工作负载都是无服务器的良好候选者，那么这一次就足够了。但是，如果您的工作负载延迟了（例如，网络带宽限制），则可能无法及时完成。您可以通过将无服务器实例链接在一起来解决这个问题，但这是一个笨拙的解决方案，在大多数情况下，只需坚持使用其他部署解决方案，您就会变得更好。
5.您使用不受支持的语言
并非每种功能都可以移动到无服务器平台。大多数无服务器环境仅支持使用特定语言编写的代码。在某些情况下，您可以使用包装器或其他技巧来运行其他类型的代码，但一般来说，您的选项仅限于一组核心编程语言。
如果您选择使用您选择的无服务器平台不支持的语言编写给定函数，那么您根本无法对该特定工作负载使用无服务器计算。
结论
无服务器计算是一件好事。本文的目标不是要否定它。
相反，这里的要点是，因为无服务器对许多类型的工作负载都很有用，所以它并不适合所有类型的工作负载。在跳上无服务器的潮流之前，请退一步评估您的工作负载是否真正受益于无服务器启用的功能。