為什麼無伺服器化是2018年建立 APIs 的唯一方法？
【編者的話】從最早的物理伺服器開始，我們都在不斷地抽象或者虛擬化伺服器。我們使用 XEN、KVM等虛擬化技術，隔離了硬體以及執行在這之上的作業系統。我們使用雲端計算進一步地自動管理這些虛擬化的資源。我們使用 Docker 等容器技術，隔離了應用的作業系統與伺服器的操作。現在，我們有了 Serverless，我們可以隔離作業系統，乃至更底層的技術細節。
如果當你在自己的 web app 中建立 API 不合邏輯或不實用時，有三種主要方法可以建立API。你可以使用虛擬機器（如 AWS EC2 例項）建立一個服務，使用一個容器建立你的服務，或者建立在一個無伺服器的環境中。
這裡，我們說說為什麼採用無伺服器架構建立 APIs 是最有效的。
## 不要用容器去建立 API ##容器是近年來最令人費解的時尚。在某些情況下，能夠說“我們可以建造新機器，這是你之前建造的機器的完美複製品”，這是一種超能力，它解鎖了一些關鍵過程——但是，公共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的情況下，很難找到比無伺服器架構更好的方案。
原文連結： ofollow,noindex" target="_blank">Why Serverless Is the Only Way to Build APIs in 2018 （翻譯：Sam）