2015 年，第一个使用 AWS Lambda 和 API 网关的教程出现了，它主要关注的是如何复制微服务。但是，随着时间推移，那些大规模使用 AWS Lambda 的人越来越清晰地意识到，使用 AWS Lambda 的微服务存在严重的局限性。
首先说说为什么会有微服务？
微服务之所以会出现，主要是因为单体应用程序存在不足。简单地说，单体就是把所有逻辑都塞进同一个逻辑代码库的应用程序。
在单服务器环境时代，多服务器价格十分昂贵。默认情况下，应用程序是按照单服务器的方式进行构建的。部署一个单体就是把应用程序的一部分或者整体部署到一台服务器上。
在部署单体时，必须确保不出任何问题。通常，一个很小的改动都会导致整个应用程序和服务器宕机。
在云服务出现之后，通过简单的操作就可以在几分钟而不是几天或者几周之内分配好服务器实例，这就为关注点分离提供了条件。
于是，拆分单体就成了一件势在必行的事情，微服务也就孕育而生。
你不再需要把所有逻辑都部署在同一个实例或服务器上，你可以把不同的部分放在不同的实例上，然后使用轻量级的通信协议（比如 HTTP API）把它们连接起来。
于是，应用程序架构就从单体转向了微服务。
微服务的价值在于，在做出修改时，你修改的不是整个代码库，而是其中的一个微服务，它只是整个应用程序的一部分。也就是说，改动不会造成整个应用程序宕机。
但这毕竟也只是一个美好的理论，一个比单体更好的理论，在现实中，它并不完美。
服务接口（通常是 HTTP 接口）是微服务的关键所在。这本没有什么问题，但是，当存在大量的服务时，要协调好它们就成了一个大问题。
向 Serverless 架构转变
AWS 上的第一个 Serverless 应用就是一个微服务：一个 API 网关接口，网关背后是 Lambda 函数和路由器。
每一个 API 网关都是一个服务接口，看起来似乎是合乎逻辑的。
你可以构建一系列的服务，每个服务都可以独立伸缩，某种程度上说，这样做非常合理。
但问题是，AWS Lambda 和 FaaS 不应该被当作实例或服务器看待。
因为底层使用了服务器（互联网上的很多东西都运行在服务器之上，但就是没有人指出“S3 也是有服务器的”、“BigTable 也是有服务器的”或者“Azure Active Directory 也是有服务器的”），所以我们假设你应该简单地把 FaaS 函数看成是服务，也就是有些人所谓的“minilith”。
但问题是，Serverless 的关键点是事件，而这一点往往被忽略掉。
