Serverless是一種構建和管理基於微服務架構的完整流程，其中應用開發不使用常規的服務進程，僅依賴於第三方服務（如AWS Lambda服務）、客戶端邏輯和服務託管遠程過程調用的組合，可以幫助開發者更快速地開發軟件。Serverless意味無維護，有了Serverless，我們幾乎無需DevOps了。本文作者講述了他學習Serverless，嘗試託管API的經歷。
最近，我想更改CardGames.io上的API，同時嘗試一下Serverless框架。因爲在過去的幾年中，Serverless一直是技術界的熱門話題，而我喜歡靠嘗新來保持自己的技術水平不過時，所以我決定花幾個小時來學習Serverless，看看用它來託管我們的API是否可行。
原有設置
CardGames.io託管在AWS上。我們使用S3來存儲HTML頁面、CSS、JavaScript和圖像。我們有一個使用C#編寫的API，該API託管在Elastic Beanstalk上，使用運行 .NET Core和Docker的Linux服務器。最後，我們在S3的靜態文件和API上都部署了CloudFront CDN。
下圖是我們今年8月的EC2賬單。我們還有其他一些實例，但對於API，我們使用m1.small實例（是的，我們可能應該使用t2.small）和經典負載平衡。把圖中紅框部分加起來可以得出該月的費用爲164.21美元，我甚至包括了整個EBS的部分，主要是因爲我不確定它的哪一部分屬於我們運行的其他EC2內容。
我們有兩個環境，每個環境都有1-3個實例，一個處於活動狀態，剩下的則是非活動狀態。之所以有兩個環境，是因爲在AWS的Docker中部署 .NET Core需要幾分鐘，因此我們部署到非活動環境，然後切換CNAME記錄以切換到新部署的環境。部署緩慢是我想嘗試新事物的原因之一。我們還有其他一些服務器在Beanstalk上運行node.js應用程序，這些服務器可以在幾秒鐘內部署，我也希望將其用於我們的API。
走向Serverless
我瀏覽了一個關於使用Serverless框架託管ASP .NET Web API的優秀教程。我發現，只需在現有的API項目中添加一個簡單的配置文件、一個依賴項和一個小小的啓動類即可。然後我就部署了，大概花了20秒，比部署到Beanstalk快得多。我猜這是因爲Lambda內置了對 .NET Core的支持（儘管只有2.2版本），而在Beanstalk中，僅當你使用Docker並自行管理時才能支持。不管怎樣，到目前爲止我還是很高興，還沒有考慮自動擴展組、最大實例數之類的東西。
測試性能
AWS上的Serverless是Lambda，它實際是函數的宿主，而API網關是一個前端，它允許用戶添加速率限制和API密鑰等內容。我在us-west-2區域設置了Lambda函數，該區域就是我們託管Beanstalk服務器的那一個。然後，我設置CloudFront實例，將一個遊戲的請求路由到新的Serverless設置，同時將另一個遊戲路由到舊的Beanstalk設置。後來，我對兩個URL（Serverless和Beanstalk）進行了簡單測試。兩個網址在我們的API中指向了完全相同的代碼，將一個事件保存到數據庫中。我爲每次測試運行了100個請求，結果是：
我發現，Serverless設置的速度始終慢15％（如果你認爲總體運行速度也很慢，那是因爲我是在冰島運行的，可能會有些延遲）。這個結果令人失望，但也足夠快了。我知道在API之前運行API網關會有一些開銷，它提供了很多東西，有些我們可能用不上，所以結果雖然令人失望，但還不算糟糕！
價格
老實說，我之前根本沒有考慮過價格。我覺得“爲你所用的內容付費”聽起來比爲24/7運行的實例付費要便宜，因此我讓新的Serverless設置運行了幾天，然後檢查我的賬單。天啊！Lambda+API網關賬單已經超過了一百美元！我先鼓搗了一通Lambda設置，減少了lambda函數使用的內存以減少費用。當我真正開始研究到底發生了什麼事時才發現，罪魁禍首明顯是API網關。以下是它的費用：
我們的API每天接受大約一千萬個請求。光是API網關，每天就要花費大約35美元。除此之外，Lambda每天要花費大約10美元，儘管可以通過減少內存使用來降低一些。二者合計約爲每天45美元，也就是每月1350美元，而Elastic Beanstalk大約是每月164美元，高出整整8倍！我喜歡新技術，入門也很快，但我不會爲它每月額外支付約1200美元。所以，回到Beanstalk！
結論
好吧，我應該先好好看看AWS定價並做出一些計算，再考慮更改。但這樣的話，我就只好去幹正經事，而沒法學到寶貴的技能了！我知道在某些情況下，API網關和Lambda優於Elastic Beanstalk，但我想我們的情況不在其中。也許你使用的是API密鑰和速率限制之類由API網關提供的內容，那麼就有必要爲每一百萬個請求支付3.5美元。對我們來說，只要可以在Lambda前面放一個普通的負載平衡器就更好了。據我所知，API網關對Lambda的http訪問是必需的。
即使我們只爲Lambda付費，以每天10美元的價格，我們每月仍需支付300美元，而不是164美元。我們有很多請求，但每個請求的內容很少，基本是一個數據庫調用。以下是一個請求的報告，你可以看到我們的計算時間只有3.5毫秒，而要爲100毫秒計費似乎是一個很大的浪費。
最後，我並不打算抨擊API網關、Lambda或Serverless，只是想說明對於某些工作負載，它們比無聊的舊EC2和Elastic Beanstalk要昂貴得多。這就是我們堅持老路子的原因🙂。或許也有更好或更有效的設置方式，如果你看出了一些明顯的錯誤，請務必在評論中指出來。
2019.9.26更新：這篇文章在3天內獲得了超過10萬的瀏覽量，併成爲了Hacker News和reddit.com/r/programming的頭條。我的確學到了一些東西。我應該在Lambda之前使用應用程序負載均衡器而非API網關；我應該將古老的m1.small實例升級爲新的實例類型；使用運行時 .NET Core docker鏡像而非SDK鏡像；我能夠將Beanstalk的部署時間降低到合理的30—40秒。
雖然，Serverless仍不適合我的用例，但這絕對是一次有趣的實驗！
原文鏈接：
https://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/