在传统的Web应用程序架构中，你必须管理基础架构，并确保其满足可扩展性和安全性需求。例如，客户端在一边，服务器在另一边。客户端发送一个“请求”，服务器回复“响应”。但是，如果无法满足应用程序需求，则很快就要扩展服务器端了。
现在，这可以通过多种方式完成。一种方法是通过扩展服务器，通过使用更强性能的服务器增加容量。另一种方法是横向扩展服务器，添加额外的服务器来处理负载。在这种情况下，还必须部署负载平衡，以便“决定”如何平衡两台或多台服务器之间的负载。这意味着你必须管理此设置，对其中一个服务器发生故障或负载平衡发生故障时采取预防措施。
在成本方面，即使没有充分利用，也必须支付所有这些组件的分配，包括虚拟机、负载平衡，存储等。这需要对这些资源进行适当规划和管理的投资。虽然一些云提供商提供“按需付费”模式和“弹性定价”，但仍然需要决定如何实施架构。对于Web应用程序开发人员来说，通常是后者。
无服务器模型提供了完全不同的方法。与传统架构不同，无服务架构在无状态计算容器中运行，这些容器是事件触发的，短暂的(只能持续一次调用)，并由第三方完全管理。就像一个“黑盒子”，这个服务你只需上传代码并实时自动处理。当一个请求进来时，就会运行你的Lambda功能的容器。
在成本方面，使用无服务器模型，通常仅支付服务请求和运行代码所需的计算时间。计费以100毫秒为单位进行计量，使其具有成本效益，并且易于自动从每天几个请求到每秒数千次都可以。
无服务器架构如何工作
在传统的Web应用程序架构中，你必须管理基础架构，并确保其满足可扩展性和安全性需求。例如，客户端在一边，服务器在另一边。客户端发送一个“请求”，服务器回复“响应”。但是，如果无法满足应用程序需求，则很快就要扩展服务器端了。
现在，这可以通过多种方式完成。一种方法是通过扩展服务器，通过使用更强性能的服务器增加容量。另一种方法是横向扩展服务器，添加额外的服务器来处理负载。在这种情况下，还必须部署负载平衡，以便“决定”如何平衡两台或多台服务器之间的负载。这意味着你必须管理此设置，对其中一个服务器发生故障或负载平衡发生故障时采取预防措施。
在成本方面，即使没有充分利用，也必须支付所有这些组件的分配，包括虚拟机、负载平衡，存储等。这需要对这些资源进行适当规划和管理的投资。虽然一些云提供商提供“按需付费”模式和“弹性定价”，但仍然需要决定如何实施架构。对于Web应用程序开发人员来说，通常是后者。
无服务器模型提供了完全不同的方法。与传统架构不同，无服务架构在无状态计算容器中运行，这些容器是事件触发的，短暂的(只能持续一次调用)，并由第三方完全管理。就像一个“黑盒子”，这个服务你只需上传代码并实时自动处理。当一个请求进来时，就会运行你的Lambda功能的容器。
在成本方面，使用无服务器模型，通常仅支付服务请求和运行代码所需的计算时间。计费以100毫秒为单位进行计量，使其具有成本效益，并且易于自动从每天几个请求到每秒数千次都可以。
降低运营成本 - 如果你考虑这个问题，无服务架构本质上是一个外包解决方案。基础设施不会消失。然而，与常规云服务相比，事实上，只需要根据流量规模和形式支付需要的计算量，这可能会大大节省运营成本，特别是对于具有不同变化的早期和动态应用负载要求。
无限可扩展性 - 极高的可扩展性在云服务领域并不新鲜，但无服务架构将其提升到一个全新的水平。无服务架构的缩放功能不仅可以降低计算成本，还可以减少运行管理，因为缩放是自动的。使用无服务器，无需明确添加和删除实例到服务器阵列，并让供应商为你扩展应用程序。由于云计算提供商根据每个请求执行扩展，所以甚至不需要考虑在内存不足之前可以处理多少并发请求的问题。
分离问题 - 无服务器几乎迫使你实施关注模型的分离，通过该分离将应用程序分成不同的部分，以使每个部分都解决一个单独的问题。
隔离进程 - 在无服务器环境中，每个Lambda函数都完全隔离。如果其中一个功能关闭，它不影响其他功能，它不会导致服务器崩溃。
使用无服务器架构的缺点
缺乏控制权 - 通过任何外包策略，你都可以将某些系统的控制权给第三方供应商。由于系统停机，意外的限制，成本的变化，功能的丧失，强制的API升级等，这种缺乏控制可能会显现出来。此外，如果需要专门的服务器进行专门的流程，那么必须自己运行这个专门的服务器。一个无服务器架构，在大多数情况下，提供商业化的基础设施，将以广义的方式运行你的流程。
长时间运行流程的高成本 - 如果你的进程持续运行很长时间，则可能会需要运行自己的服务器。因为这不仅涉及到成本，还涉及到拥有的技能或者想要投入运行自己的服务器的专注;在评估这些解决方案时，请考虑所有这些方面。
供应商锁定将基础架构管理完全外包给无服务器提供商，无疑将自己锁定到该供应商。每个供应商都有自己的标准和编程框架，不容易改变。在几乎每一种情况下，无论从供应商使用的无服务器功能，将由另一个供应商进行不同的实现。如果要切换供应商，几乎肯定需要更新操作工具(部署，监控等)，可能还需要更改代码。
如果你将应用程序分解成微服务，则无服务器架构是一个很好的选择。它不太适合运行专门过程的长时间运行的应用程序。虽然无服务架构还流于趋势，但是由于更多的开发者采用它并将其带入主流，所以这个市场的所有玩家都期望有重要的创新和新功能。基础设施不会消失。然而，与常规云服务相比，事实上，只需要根据流量规模和形式支付需要的计算量，这可能会大大节省运营成本，特别是对于具有不同变化的早期和动态应用负载要求。
无限可扩展性 - 极高的可扩展性在云服务领域并不新鲜，但无服务架构将其提升到一个全新的水平。无服务架构的缩放功能不仅可以降低计算成本，还可以减少运行管理，因为缩放是自动的。使用无服务器，无需明确添加和删除实例到服务器阵列，并让供应商为你扩展应用程序。由于云计算提供商根据每个请求执行扩展，所以甚至不需要考虑在内存不足之前可以处理多少并发请求的问题。
分离问题 - 无服务器几乎迫使你实施关注模型的分离，通过该分离将应用程序分成不同的部分，以使每个部分都解决一个单独的问题。
隔离进程 - 在
无服务器环境中，每个Lambda函数都完全隔离。如果其中一个功能关闭，它不影响其他功能，它不会导致服务器崩溃。
使用无服务器架构的缺点
缺乏控制权 - 通过任何外包策略，你都可以将某些系统的控制权给第三方供应商。由于系统停机，意外的限制，成本的变化，功能的丧失，强制的API升级等，这种缺乏控制可能会显现出来。此外，如果需要专门的服务器进行专门的流程，那么必须自己运行这个专门的服务器。一个无服务器架构，在大多数情况下，提供商业化的基础设施，将以广义的方式运行你的流程。
长时间运行流程的高成本 - 如果你的进程持续运行很长时间，则可能会需要运行自己的服务器。因为这不仅涉及到成本，还涉及到拥有的技能或者想要投入运行自己的服务器的专注;在评估这些解决方案时，请考虑所有这些方面。
供应商锁定将基础架构管理完全外包给无服务器提供商，无疑将自己锁定到该供应商。每个供应商都有自己的标准和编程框架，不容易改变。在几乎每一种情况下，无论从供应商使用的无服务器功能，将由另一个供应商进行不同的实现。如果要切换供应商，几乎肯定需要更新操作工具(部署，监控等)，可能还需要更改代码。
如果你将应用程序分解成微服务，则
无服务器架构是一个很好的选择。它不太适合运行专门过程的长时间运行的应用程序。虽然无服务架构还流于趋势，但是由于更多的开发者采用它并将其带入主流，所以这个市场的所有玩家都期望有重要的创新和新功能
戴尔服务器销售中心
