為什麼說無伺服器是2018年構建API的唯一之道？
【51CTO.com快譯】從你自己的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為例，很難為除了無伺服器外的任何解決方案找到充分的理由。
原文標題：Why Serverless Is the Only Way to Build APIs in 2018，作者：Toby Fee
【51CTO譯稿，合作站點轉載請註明原文譯者和出處為51CTO.com】