虚拟机、容器和无服务器架构都有明显的优缺点，但如果应用程序不适合无服务器计算，这种部署架构可能会破坏一切。为了防止IT出现灾难，就要让开发人员对无服务器与容器进行合理的评估，以便从中选择一种来部署新的应用程序。
想确定容器或无服务器计算哪个适合，就要比较每一种架构的功能、它将托管的应用程序的用户群以及成功部署所需的要素。
虽然虚拟机不在本文讨论范围之内，却是IT部门中最常使用、最广人为知的应用程序托管架构。它是最普遍的基础设施抽象方法，不过缺点是很复杂和资源开销大。本文主要比较无服务器计划与容器，前者完全抽取资源，后者是操作系统上一个轻量、快速的隔离层。
应用程序需要什么？
无服务器云计算的经济效益在于，企业只需要在应用程序运行时为计算资源和应用程序的执行时段付费，空闲时段无需付费。无服务器最适合必须总是准备好，但不总是在运行的应用程序和组件。
图1：亚马逊网络服务（AWS）上的无服务器计算架构显示了无服务器如何将应用程序与支持它们的硬件隔离开来
比如说，湿度传感器表明土壤干燥、需要浇水时，物联网农业应用程序生成事件。这种传统部署环境中的应用程序可能在下雨的天气中处于空闲状态，等待被激活，耗用不必要的资源。而容器系统可以减少应用程序消耗的资源数量，但无服务器计算可以在空闲期间消除资源。应用程序空闲的时间越长，无服务器的优点就越大。是不是很简单？
与往常一样，实际情况要来得复杂。无服务器架构的好处包括，可以在几毫秒内让这个示例物联网应用程序准备好，而不是像容器化系统那样需要几十秒，但容器化部署比较长的启动时间不太可能影响物联网应用程序实现其用途的能力。并不是空闲时间多于活动时间的每个应用程序都适合无服务器。无服务器系统逻辑不仅费用比容器系统来得高，而且技术上也不同。
无服务器vs容器技术
如果你深入研究无服务器的细节时，会发现如下术语：
- 微服务：应用程序分解为多个更小、可独立扩展和部署的组件；
- 函数计算：负责托管的云按需执行应用程序函数，函数作为一项服务；
- lambda函数：这种匿名C++函数转换传递给它们的数据集合，然后生成新的集合；
- 无状态：不使用或不需要来自之前使用事件的数据的应用程序。
无服务器云计算旨在实现与上下文无关的处理，面向无状态应用程序。当无服务器应用程序被事件激活后，它们从根本不记得过去的代码副本开始，依赖之前出现的事件或请求的任何事件都是有状态的。如果你启动第二个无服务器架构副本来处理更多的工作，这第二个副本就不会自动知道第一个副本一直在做什么。
可以通过客户端或后端状态控制，让有状态应用程序在无服务器部署中环境运行，但这必须写入到应用程序的代码中。这种选择可能不会存在于第三方软件中。即使某企业的应用程序是内部编写的，想在无服务器部署环境中实现有状态行为也需要可能复杂而昂贵的更改。
图2：Docker容器托管模式将应用程序代码从底层的硬件资源中抽取出来
容器可以运行几乎任何应用程序或应用程序组件，无需对代码进行重大更改。而无服务器做不到这点。大多数业务应用程序执行事务处理，其中一个或多个数据库被更新，这给无状态行为提出了更艰巨的挑战。事务处理应用程序无状态会导致事务冲突：针对库存或账户余额的两个查询独立报告销售或取款，结果却发生冲突，导致余额在零以下。企业可以结合无状态行为和事务行为，重新设计或改造应用程序，但这是个复杂的过程，需要经验和大量工作。容器则没有这个要求。
连接到现实
开发人员将无服务器与容器视作哪个最适合应用程序的问题，但他们也要权衡每种方案的部署问题。容器网络是显式的，基于IP子网络，这是最常见的应用程序部署模式。容器系统在应用程序中使用专有的IP地址空间，但管理员可以选择性地公开组件地址，向虚拟专用网络或互联网上的用户或其他应用程序提供服务。如果使用无服务器计算，负载均衡和网络寻址以及其他操作方面由无服务器云框架处理，你可能需要采取特殊步骤，将无服务器组件与托管在数据中心中较传统的云上的应用程序组件集成起来。
容器需要一个长期的托管位置，而无服务器不需要。容器可以支持广泛的社区访问应用程序和服务，响应时间良好，但前提是你在每个地理区域都部署副本。这种部署模式可以划分工作，在各应用程序副本之间创建更多的闲置时间，从而增加成本。相比之下，只要有可用资源，无服务器应用程序就可以在任何地方运行工作负载的任意数量的副本。
如何托管微服务？
微服务是可以独自共享和扩展的分布式应用程序代码的独立式组件，适合部署在容器中和无服务器云上。差异化因素归结为你有哪种类型的微服务。由于微服务是无状态的，因此适合无服务器部署。但是，微服务常常是多个应用程序共享的通用组件。当微服务被组合到几个不同的应用程序中时，容器托管是比无服务器更好的一种部署选择。由于按需部署无服务器组件的请求，无服务器微服务经常使用的话，会导致应用程序的响应时间大幅延长。
无服务器会不断发展，但无服务器与容器在技术和成本管理这两个层面都有明显差异。在某些情况下，这些差异会让企业选择一个、而不是另一个来得很容易；而在另一些情况下，应用程序规划人员必须采用混合模式，尽管这增加了一点复杂性。毕竟不存在一应俱全式的方案。
