【51CTO.com快譯】從你自己的Web應用程序里面創建API不合邏輯或不切實際時，有三種主要的方法可以創建API。你可以使用虛擬機(比如AWS EC2實例)構建服務，使用你的服務構建容器，或者在無服務器環境中構建。

下面解釋了為什么在構建API時采用無服務器最有意義。

[[244591]]

別使用容器來構建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為例，很難為除了無服務器外的任何解決方案找到充分的理由。

原文標題：Why Serverless Is the Only Way to Build APIs in 2018，作者：Toby Fee

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】