Serverless在2021年狀況報告 | Datadog

Lambda 函式的呼叫頻率是兩年前的 3.5 倍
AWS Lambda 透過構建高度可擴充套件的應用程式使開發人員能夠更快地進行創新，而無需擔心基礎設施。如今，團隊不僅在試驗無伺服器，而且將其作為其軟體堆疊的關鍵部分。事實上，我們的研究表明，自 2019 年以來一直使用 Lambda 的公司已經顯著增加了使用率。平均而言，在 2021 年初，函式每天被呼叫的頻率是兩年前的 3.5 倍。此外，在同一組 Lambda 使用者中，每個組織的功能平均每天執行 900 小時。
 

Azure Functions 和 Google Cloud Functions 勢頭強勁
AWS Lambda 可能已經啟動了無伺服器運動，但它並不是鎮上唯一的遊戲。Azure Functions 和 Google Cloud Functions 在各自的雲平臺中的採用率都在增長。在過去的一年中，執行 Azure Functions 的 Azure 組織的份額從 20% 攀升至 36%。在 Google Cloud 上，近四分之一的組織現在使用 Cloud Functions。儘管 Cloud Functions 是推出的三個 FaaS 產品中的最後一個，但無伺服器在Google Cloud中並不是一個新概念——雲平臺早在 2008 年就推出了 Google App Engine，這是它的第一個完全無伺服器的計算服務。但今天，我們看到了勢頭的轉變轉向谷歌較新的無伺服器產品，即 Cloud Functions 和 Cloud Run。
 

今天的 Lambda 呼叫比一年前短得多
Lambda 越來越多地用於為需要低延遲的面向客戶的應用程式提供支援。2020 年，Lambda 呼叫的中位數僅用了 60 毫秒——大約是前一年值的一半。一種可能的解釋是，越來越多的組織正在遵循Lambda 最佳實踐並設計高度特定於其工作負載的功能，這有助於縮短呼叫的持續時間。我們還注意到延遲分佈的尾部很長，這表明 Lambda 不僅支援短期工作，而且還支援計算密集型用例。
 

Step Functions 為從 Web 應用到資料管道的一切提供支援
AWS Step Functions 使開發人員能夠構建涉及多個 Lambda 函式和 AWS 服務的事件驅動工作流。在這些工作流中，Step Functions 協調錯誤處理、重試、超時和其他應用程式邏輯，這有助於在無伺服器應用程式擴充套件時降低操作複雜性。我們的研究表明，平均 Step Functions 工作流包含 4 個 Lambda 函式——我們看到這個數字逐月增長。
Step Functions 提供兩種型別的工作流程：標準和快速。我們注意到超過 40% 的工作流在一分鐘內執行，這表明組織很可能使用快速工作流來支援大容量事件處理工作負載。但是，儘管許多工作流執行得很快，但其他工作流會執行一天多。事實上，最長的 Step Function 工作流執行時間超過一週。Step Functions 工作流可以包括活動工作人員例如，在 Amazon ECS 或 EC2 例項上執行的例項，這意味著它們能夠執行比 Lambda 函式超時 15 分鐘更長的時間。這使 Step Functions 能夠支援大量用例，從延遲關鍵任務（如 Web 請求處理）到複雜、長時間執行的任務（如大資料處理作業）。
 

四分之一的 CloudFront 使用者已接受無伺服器邊緣計算
邊緣計算因其對更快資料處理的承諾而引起了很多關注。如今，四分之一的使用 Amazon CloudFront 的組織正在利用 Lambda@Edge 為其全球使用者群提供更加個性化的體驗。例如，Lambda@Edge 可以根據使用者特徵（例如，裝置型別）動態轉換影像或為不同版本的 Web 應用程式提供 A/B 測試。
透過利用 CloudFront 的邊緣站點網路，Lambda@Edge 使組織能夠更接近終端使用者地執行功能，而無需設定和管理源伺服器的複雜性。我們的資料顯示，67% 的 Lambda@Edge 函式在 20 毫秒內執行，這表明無伺服器邊緣計算具有巨大的潛力，可以以最小的開銷支援對延遲最敏感的應用程式。隨著這項技術的成熟，我們希望看到更多的組織依賴它來改善他們的終端使用者體驗。
  

組織公司在大多數功能的預配置併發上超支
當 Lambda 函式在一段時間不活動後被呼叫時，它會經歷短暫的執行延遲，稱為冷啟動。對於需要毫秒級響應時間的應用程式，冷啟動可能無法啟動。2019 年底，AWS 引入了預置併發，透過保持執行環境初始化並準備好響應請求來幫助 Lambda 使用者對抗冷啟動。
根據我們的資料，似乎為 Lambda 函式配置最佳預置併發量仍然是使用者面臨的挑戰。超過一半的函式使用不到 80% 的配置預配置併發。同時，超過 40% 的函式使用了它們的全部分配，這意味著它們可能仍然會遇到冷啟動，並且會從更多的併發中受益。Application Auto Scaling提供了一種解決這些問題的方法，允許使用者根據利用率自動擴充套件預配置併發。
我們還看到，預配置併發更常用於 Java 和 .NET Core 函式，由於這些執行時的固有特性，這些函式的啟動時間通常比 Python 或 Node.js慢。例如，Java 需要初始化其虛擬機器 (JVM) 並將大量類載入到記憶體中，然後才能執行使用者程式碼。
 
 

無伺服器框架是使用 AWS CloudFormation 部署 Lambda 應用程式的主要方式
隨著無伺服器應用程式的擴充套件，手動部署 Lambda 函式和其他資源很快就會變得很麻煩。AWS CloudFormation 允許開發人員在集合（稱為堆疊）中預置 AWS 基礎設施和第三方資源，並且是 AWS 雲開發工具包 (CDK)、AWS 無伺服器應用程式模型 (SAM) 和無伺服器框架等框架的底層部署機制。
在這些工具中，開源無伺服器框架是迄今為止最受歡迎的——如今，超過 90% 的組織都在使用它，這些組織透過 AWS CloudFormation 管理其無伺服器資源。除了無伺服器框架，19% 的組織使用 vanilla CloudFormation，18% 使用 AWS CDK，13% 使用 AWS SAM。請注意，由於每個組織可能使用多個部署工具，因此這些值加起來超過 100%。
在無伺服器應用程式中使用的 CloudFormation 堆疊中，65% 僅包含一個 Lambda 函式。此外，超過一半的功能（57%）未使用 CloudFormation 部署。這表明，許多組織仍處於使用基礎設施即程式碼自動化和最佳化其無伺服器工作流的早期階段。但正如 Kubernetes 和 Amazon Elastic Container Service (ECS) 等編排器對於管理大量容器變得必不可少一樣，我們預計基礎設施即程式碼工具在大規模部署無伺服器應用程式方面將扮演更重要的角色。
 

Python 是最流行的 Lambda 執行時，尤其是在大型環境中
自 2018 年以來，Lambda 已提供對六種執行時的支援：Node.js、Python、Java、Go、.NET Core 和 Ruby。然而，Python 和 Node.js 繼續在 Lambda 使用者中佔據主導地位，佔函式的近 90%。所有部署的 Lambda 中有 58% 執行 Python（比一年前上升 11 個百分點），另有 31% 執行 Node.js（與去年相比下降 8 個百分點）。
當我們檢查按環境大小劃分的執行時使用情況時，出現了一個有趣的趨勢：雖然 Node.js 在小型 AWS 環境中超越 Python，但隨著環境規模的增長，Python 變得越來越流行。在 AWS 足跡最大的組織中，Python 的使用頻率是 Node.js 的四倍。
 截至 2021 年 3 月，按版本劃分的頂級執行時是：

1. Python 3.x
2. Node.js 12
3. Node.js 10
4. Python 2.7
5. Java 8
6. Go 1.x
7. .NET Core 2.1
8. .NET Core 3.1