为什么无服务器化是2018年创建 APIs 的唯一方法？

【编者的话】从最早的物理服务器开始，我们都在不断地抽象或者虚拟化服务器。我们使用 XEN、KVM等虚拟化技术，隔离了硬件以及运行在这之上的操作系统。我们使用云计算进一步地自动管理这些虚拟化的资源。我们使用 Docker 等容器技术，隔离了应用的操作系统与服务器的操作。现在，我们有了 Serverless，我们可以隔离操作系统，乃至更底层的技术细节。

如果当你在自己的 web app 中创建 API 不合逻辑或不实用时，有三种主要方法可以创建API。你可以使用虚拟机（如 AWS EC2 实例）创建一个服务，使用一个容器创建你的服务，或者创建在一个无服务器的环境中。

这里，我们说说为什么采用无服务器架构创建 APIs 是最有效的。

容器是近年来最令人费解的时尚。在某些情况下，能够说“我们可以建造新机器，这是你之前建造的机器的完美复制品”，这是一种超能力，它解锁了一些关键过程——但是，公共API很少需要启动数十个副本，而这种优势并不会超过许多困难。

与虚拟机（VM）相比，容器启动更快，并且需要更少的资源就能运行多个容器，但这些都不很适用于API服务。通常，容器启动速度不够快到等待接收API请求。与传统虚拟机相比，我们的开销较低，而且我们在这里得出了一个基本的开发事实：没有高管抱怨他们不能购买更多内存，但他们缺少工程师。没有人会写一行 Javascript，如果它是RAM或CPU周期非常宝贵。大多数被广泛采用的技术主要是为了节省开发人员。

容器如何以开发时间为代价来节省RAM的一个例子是缺乏可靠的管理工具。这是一个单一的轶事，但我从未遇到过Amazon EC2或Azure VM的虚拟机管理程序界面的问题。另一方面，我从未成为（或甚至遇到过）管理Docker容器的自学成才的专家。

当面对大多数 Web 开发人员面对容器时遇到的一些基本困难时，答案往往是“通过一些培训，您可以轻松地管理这个或那个”，这使我们遇到容器的根本问题：在他们的介绍几年后，web 开发人员仍然无法自己解决问题。一般来说，当领导者谈论哪些资源供不应求时，就会出现“工时不足”而不是技术问题。需要更多工程师时间的解决方案似乎注定要造成比它的价值更多的麻烦。

## 不要将虚拟机用于您的API ##

虽然我对容器的争论很漫长，但我反对使用虚拟机的论点归结为一个词：安全性。实际上，VM的噩梦场景是一种类似公共API的服务。想象一下如下：

• 您的团队被要求建立一个公共API，以帮助建立一个并行服务的潜在合作伙伴关系;
• 在开发之后，几个月或几年过去只有中等社区对端点的兴趣，公司的所有开发人员都转向其他东西;
• 在那个时候，我们的虚拟机操作系统出现了新的漏洞，但由于公共API不是任何人的全职“工作”，因此这些更新要么不会发生，或者如果管理程序服务强制它们，当没有人可以找出他们为什么破坏服务时，他们必须回滚;
• 再过一两年，你会收到一封来自黑客的电子邮件，说明他们如何通过很久以前打过补丁但从未应用到你的 AP 虚拟机的安全漏洞完全克隆你的生产数据库。

## 为什么无服务器赢了 ##

无服务器正在“跨越”容器的趋势。许多新开发人员在像 Heroku 这样高度抽象的环境中管理虚拟机的最简单的速成课程之后，正在学习无服务器。

无服务器提供了一个环境，在这个环境中，更新和安全漏洞正式“不是您的问题”，您可以采取一种“如果没有破坏而不修复它”的态度，那么这些服务已经可靠地工作了一段时间。

最后，使用单个函数（在AWS中他们将是Lambdas）来处理单个路由意味着通过API泄漏数据的危险将会降低。无服务器可能无法提供优越的资源使用，定价或易于复制，但这些都不是交易破坏者，尤其是在构建公共API时。Stackery，我们专门解决了许多这些问题，使开发人员更容易使无服务器应用程序快速启动和运行。

对于内部服务，任务关键型项目和分布式系统，可以对几乎任何现存技术进行论证。在构建API的情况下，很难找到比无服务器架构更好的方案。

原文链接： Why Serverless Is the Only Way to Build APIs in 2018 （翻译：Sam）