构建API无服务器才是最后的赢家

从你自己的Web应用程序里面创建API不合逻辑或不切实际时，有三种主要的方法可以创建API。你可以使用虚拟机(比如AWS EC2实例)构建服务，使用你的服务构建容器，或者在无服务器环境中构建。

下面解释了为什么在构建API时采用无服务器最有意义。

别使用容器来构建API

容器是近年来最令人迷惑的时尚。在某些情况下，“我们可以构建是你之前构建的机器的完美复制品的新机器”有莫大的吸引力，还充分发掘一些关键流程，但公共API很少一开始就需要启动几十个复制品，这个优势无法压倒诸多困难。

与虚拟机相比，容器启动速度更快，只需较少的资源即可多路运行，但这两个优点没一个适用于API服务。通常，容器启动速度不够快，等到收到API请求才开始。与传统虚拟机相比，我们的开销较低，这里就引出了一个基本的开发事实：没有哪个高管抱怨买不到更多的内存，但他们缺少工程师。如果非常稀缺的是内存或CPU周期，没人会写一行Javascript。大多数广泛采用的技术主要是为了节省开发人员的时间。

容器以牺牲开发时间来节省内存，这方面的一个例子是缺乏可靠的管理工具。这是一则轶闻，但我从未在Amazon EC2或Azure VM的虚拟机管理程序界面方面遇到过问题。另一方面，我从未成为(或甚至遇到过)管理Docker容器方面自学成才的专家。

面对大多数Web开发人员面临容器时遇到的一些基本困难时，答案常常是“稍加培训，就能轻松地管理这个或那个”，这引出了容器方面的一个根本问题：接触了多年的Web开发人员仍然无法独自解决问题。一般来说，领导者谈论哪些资源供不应求时，往往是“人时不足”，而不是技术性问题。需要更多工程师时间的解决方案似乎注定带来更多的麻烦。

别使用虚拟机来构建API

虽然我反对容器的理由有一大堆，但反对虚拟机的理由归结为一个词：安全。确实，虚拟机方面的噩梦场景就是类似公共API的服务。设想一下这个场景：

你的团队被要求构建公共API，帮助与并行服务建立起潜在的合作关系。

经过数月或数年的开发后，社区对端点的兴趣不温不火，公司的所有开发人员将注意力转到别处。

在此期间，我们所用虚拟机的操作系统出现了新的漏洞，但由于构建公共API不是任何人的“全职工作”，操作系统没有相应的更新，或者如果虚拟机管理程序服务迫使更新，但要是没有人搞清楚为什么更新搞砸了服务，就得让更新回滚或恢复。

过了一两年后，你收到了一黑客发来的邮件，解释了他们如何通过早就有补丁的安全漏洞、却从未给你API的虚拟机打上补丁，完全克隆你的生产服务器。

问题很明显，但解决方案并不是很清晰：严加管理的虚拟机让我们获得了酷似无服务器的东西，试图将服务迁移到更现代的机器映像可能要占用开发人员的大量时间。更糟糕的是，很难知道这种情况何时发生，于是你的环境中有几个确实很古老的虚拟机。

为什么无服务器是赢家?

无服务器的风头“盖过”容器趋势。许多新开发人员接受了在像Heroku这样高度抽象的环境中管理虚拟机这方面最基本的课程之后，正在学习无服务器。

无服务器提供了这样一个环境：更新和安全漏洞“不是你的问题”，你可以针对已可靠地工作了一段时间的服务，采取“如果它没有坏，别去修它”的态度。

最后，使用单个函数(在AWS中它们是Lambdas)来处理单个路由意味着通过API泄漏数据的危险将大大降低。无服务器可能无法提供出色的资源使用、定价或易复制性，但这些都不是关键的阻碍因素，尤其是在构建公共API时。在Stackery，我们专门旨在解决许多这些问题，使开发人员更容易让无服务器应用程序快速启动和运行起来。

针对内部服务、任务关键型项目和分布式系统，可以为几乎任何现存的技术找出理由。以构建API为例，很难为除了无服务器外的任何解决方案找到充分的理由。