無伺服器：速度降低15％，價格提高8倍 - einaregilsson

測試效能
在AWS上無伺服器的是Lambda（它實際上是函式的宿主）和API Gateway（它是使您新增速率限制，API金鑰等內容）的前端。我在us-west-2區域設定了Lambda函式，該區域與託管Beanstalk伺服器的區域相同。然後，我將CloudFront例項設定為將對一個遊戲的請求路由到我們的新的無伺服器設定，以及將另一個遊戲的請求路由到我們的舊Beanstalk設定。然後，我對兩個URL（一個無伺服器，一個Beanstalk）進行了簡單測試。兩個網址都在我們的API中命中了完全相同的程式碼，從而將一個事件儲存到資料庫中。我為每個請求執行了100個請求。
我始終發現，無伺服器設定的速度要慢15％。（此外，如果您認為總體執行速度很慢，那麼我是從冰島執行的，因此會有一些延遲）。令人失望，但是它仍然足夠快，我只是想知道在API之前執行API Gateway會有一些開銷，即使我們不使用它們，它也提供了很多東西。

價錢
老實說，我之前根本沒有考慮過定價。我只是覺得“為您所用的內容付費”聽起來比為24/7上的例項付費要便宜。因此，我讓新的無伺服器設定執行了幾天，然後開始檢查我的賬單。哎呦！Lambda + API閘道器賬單已經超過一百美元！我首先開始搞亂Lambda設定，為lambda函式提供更少的記憶體以減少費用，但是當我真正檢視正在發生的事情時，很明顯，主要是API閘道器費用高。
我們的API每天接受大約一千萬個請求。僅用於API Gateway每天大約35美元。最重要的是，Lambda每天的費用約為10美元，儘管可以透過使用更少的記憶體來減少。兩者合計約為每天45 $，或每月1350 $，而Elastic Beanstalk 約為每月164 $。這是8倍更貴！我喜歡新技術，並且可以快速部署，但是我不會每月額外支付約1200美元。

結論
我確定在某些情況下，API Gateway和Lambda優於Elastic Beanstalk。我想我們的用例不是其中之一。也許如果您使用的是API金鑰，速率限制和API Gateway提供的其他內容，則有必要為一百萬個請求支付3.50美元。對我們來說，如果我們可以在Lambda前面放一個普通的負載平衡器，那就更好了。據我所知，API閘道器對於HTTP訪問Lambda是必需的。
最後，在這裡我一般不打算抨擊API Gateway，Lambda或無伺服器，只是表明對於某些工作負載，它們比無聊的舊EC2和Elastic Beanstalk昂貴得多。

來自HM的討論和最佳化建議：
PSA：將現有的應用程式一對一地移植到無伺服器幾乎無法按預期進行。建議最佳化幾點：
1.不要使用.NET，它的啟動時間很糟糕。Lambda全部涉及零成本的水平縮放，但是如果您的執行時需要100毫秒以上的時間進行初始化，那將不起作用。效能敏感功能的唯一有效選項是JS，Python和Go。
2.儘可能使用託管服務。您永遠不要在Lambda中處理登入事件，這是Cognito的。
3.考慮事件而不是REST操作。考慮哪些事件必須擊中您的API，什麼可以由託管服務直接處理或由您在邊緣處理。例如。永遠不要透過Lamdba函式上傳影像，而是透過簽名的URL直接將其上傳到S3，然後讓S3發出更改事件以觸發下游處理。
4.使用GraphQL彙集來自前端的API請求。
5.對於高吞吐量的API，Websocket便宜。
6.廣泛使用快取。可以從快取處理的請求永遠不會到達Lambda。
7.始終考慮節省勞動力，尤其是人員。