本文最初發表於Datadog站點，授權InfoQ中文站翻譯分享。
現在“Serverless”可能是一個流行術語，但是它並非空洞的存在。AWS Lambda推出還不到5年的時間，就已經被近一半使用AWS基礎設施的公司所採用。在本報告中，我們分析了數千家公司的Serverless使用情況，以瞭解在現實中他們是如何使用Serverless（以及使用到了什麼程度）。
Serverless消除了提供和管理基礎設施組件(例如，服務器、數據庫、隊列，甚至容器)的必要性，能夠允許團隊專注於代碼，同時最小化他們的運維開銷。本報告將關注Serverless領域的一個子集，即所謂的“函數即服務”(functions-as-a-service, FaaS)，它提供了與公共雲相同的即付即用模型，但處於“函數”級別，而不是基礎設施組件級別。函數只是簡單的代碼片段，在用戶請求或其他事件調用時執行離散的業務邏輯。
對於本報告來說，我們會關注AWS Lambda，它在2020年初是我們的用戶羣中最成熟和被廣泛採用的Serverless平臺。在該報告的未來版本中，我們可能會研究來自其他提供商的Serverless產品，比如Google Cloud Platform和Microsoft Azure。
一半的AWS用戶已經採用了Lambda
在2020年初，Lambda已經不再是小衆的技術。使用Amazon Web Services的Datadog客戶中有近一半已經採用了Lambda。（參見文末的方法論章節以瞭解我們是如何定義採用Lambda和使用AWS的。）這樣的採用率，再結合下面章節所討論的根據環境分解的Lambda使用情況，表明Lambda並不侷限於雲原生的早期採用者和小衆使用場景。相反，在採用AWS基礎設施的各種各樣的公司中，serverless函數得到了廣泛的應用。
Lambda在大型環境中更爲普遍
令人意外的是，Lambda的廣泛採用並不是由更新、更小的公司所驅動的。相反，我們看到Lambda的採用情況與公司基礎設施環境的大小有着明顯的相關性，無論環境指的是主服務器、容器，還是serverless函數均是如此。（參見文末的方法論章節以瞭解我們規模區分的詳細信息。）在基礎設施規模最大的那些公司中，超過四分之三的公司都採用了Lambda。
使用容器的用戶已經大面積採用Lambda
在AWS中運行容器的公司特別中意於Lambda。截至2020年1月，在AWS運行容器的組織中有近80%都採用了Lambda。儘管serverless函數和容器是兩個非常不同的環境，但是它們似乎基於類似的原因而被衆人所接受，比如爲了簡化運維而抽象出基礎設施的關注點。在一些使用場景中，Lambda和容器基礎設施是直接連接的（例如，使用Lambda函數來觸發Amazon Elastic Container Service的任務），但是更多的組織可能正在分別運行它們，以滿足不同的需求。例如，某家公司可能在一個容器集羣中運行其大部分的應用程序，同時將突發的、短期運行的任務（例如支付處理）轉移到serverless的函數中。
Amazon SQS、DynamoDB與Lambda是絕配
在將函數連接至基礎設施和應用程序組件時，Lambda用戶有大量可選的技術。當函數被觸發時，它通常會將自己所產生的數據發送給消息隊列，而消息隊列可以將數據路由至其他的Lambda函數、基於服務器的應用程序或者雲服務。消息隊列能夠讓組織採用“僅爲真正使用的內容服務”的serverless模式。相對於調用其他的函數並一直等待響應（佔用可計費的調用時間），serverless可以通過消息隊列的方式進行異步調用。由於函數是臨時的和無狀態的，所以它們通常會對單獨的持久化數據存儲進行讀寫操作。
在與Lambda函數相同的請求中所調用或查詢的服務裏面，Amazon DynamoDB名列前茅。鍵值和文檔存儲非常適合Lambda函數，因爲它是一個託管的、可自動伸縮的數據存儲，可以保證低延遲。在使用Lambda的場景中，數據存儲方面另一個最流行的選擇是SQL數據庫（無論是Amazon RDS實例還是自管理數據庫）和Amazon S3。Amazon SQS（Simple Queue Service）是Lambda請求中消息隊列的首選，其次是Amazon Kinesis和Amazon SNS（Simple Notification Service）。SQS在邏輯上非常適合serverless架構：它易於搭建和擴展，成本相對較低，並且提供與Lambda的緊密集成。
Lambda用戶中，Node.js和Python佔據了主導地位
在Lambda用戶可用的語言和框架中，我們看到有兩個明顯佔據了主導地位：Python和JavaScript（藉助Node.js）。在當前所有已部署的Lambda中，有47%在運行Python，另外還有39%在運行Node.js應用。Python 3與Python 2的比例是2比1（Python 2在2020年1月正式結束了其生命）。
Python和Node.js的Lambda運行時的流行程度反映了最近應用程序開發的趨勢以及Lambda服務本身的發展。AWS在2014年首次發佈Lambda預覽版，其中Node.js就是第一個得到支持的運行時，2015年又增加了對Java和Python支持。對C#(藉助.NET
Core)、Go和Ruby的支持則是在2018年新增的。
Lambda函數運行時間的中位數是800毫秒
Lambda函數運行時間的中位數約是800毫秒，這是在所有調用中取平均值得到的，但是延遲分佈曲線的尾部很長。四分之一的Lambda函數平均執行時間超過3秒，12%的函數執行時間超過10秒。一些Lambda函數的持續時間很長，這是值得注意的，因爲serverless的延遲不僅影響應用程序的性能，還會影響雲計算的成本。Lambda定價是基於計算時間的“GB-seconds”：分配給函數的內存(詳細信息如下圖所示)，並乘以其調用的持續時間。
我們將函數持續時間的分佈放大一下可以發現，將近五分之一的函數在100毫秒內執行完成，大約三分之一在400毫秒內執行完成。
一半的Lambda函數具有最小的內存分配
如前所述，Lambda調用的成本是根據持續時間和函數內存的乘積計算出來的。因此，鼓勵運行Lambda的公司限制其函數的內存分配（這是一個可配置的設置，因此比函數的持續時間更容易控制）。實際上，47%的函數被配置爲使用最小的內存運行，即128 MB，而只有14%的函數的內存分配大於512 MB，用戶可以爲每個函數最多分配3,008 MB。
三分之二的超時時間定義都在1分鐘以下
每個Lambda函數都有一個可配置的超時設置，時間從1秒到15分鐘不等，這是Lambda調用所允許的最長持續時間。大多數函數都使用了較短的超時：三分之二的超時時間配置爲60秒或更少。(創建函數時的默認超時時間爲3秒。)
通常來講，建議的做法是使用較短的超時時間，因爲掛起函數會增加雲成本，而且Lambda應用程序架構經常需要快速響應。Amazon API Gateway通常用於在Lambda函數前提供REST接口，它的最大超時設置爲29秒。因此，API網關後面的任何Lambda函數如果響應時間超過29秒的話，都將會導致一個錯誤，即使Lambda最終成功地完成了它的工作也是如此。儘管有這些考慮因素，但是依然有許多函數都配置爲所允許超時的最大設置：當前的900秒限制以及之前的300秒限制（有效期到2018年10月）。
僅有4%的函數定義了併發限制
默認情況下，在每個region中，Lambda客戶的所有函數會有1000個併發執行的限制。用戶可以設置每個函數的併發限制，這樣的話，就能夠爲特定函數在總併發池中預留一部分。如果函數超過了它的併發限制，就會進行節流。
如今，在所有的函數中，儘管大多數組織都知道有這個可選限制，但是隻有4.2%的函數配置了併發性限制。實際上，88.6%運行Lambda的公司在其環境中至少爲一個函數使用了併發限制。定義了併發限制的函數更有可能被限流。在5天的評估窗口中，具有併發限制的函數中有8.3%至少被限制一次，而只有0.3%的函數僅受到region的限制，而不是每個函數本身的限制。
方法論
樣本
在本報告中，我們收集了Datadog客戶羣中數千家公司的使用數據。雖然Datadog的客戶涵蓋了各個公司規模和行業範圍，但他們確實有一些共同的特點。首先，他們往往對軟件基礎設施和應用程序的性能非常重視。他們比一般的人羣更傾向於採用雲平臺和服務。本文中的所有結果都存在偏見，因爲數據來自我們的客戶羣，這是一個龐大但不完美的全球市場樣本。
Lambda的採用情況
在這個報告中，我們認爲如果某家公司一個月裏至少運行五個不同的Lambda函數，那麼我們就認爲他們採用了Lambda。Datadog Forwarder函數會將S3和CloudWatch日誌等數據發送到Datadog，該函數不包含在計數中。
關於對AWS的使用
如果一個公司在一個月內至少運行5個不同的Lambda函數或5個不同的EC2實例，那麼我們就認爲該公司在使用AWS。通過這種方式，我們可以捕獲AWS用戶的基本信息，從而將它們分爲專門運行EC2實例的公司、專門運行serverless 函數的公司或同時運行這兩種功能的公司。
環境的規模
爲了評估公司基礎設施環境的相對規模，我們檢查了公司的serverless函數、容器、物理服務器、雲實例和其他基礎設施服務的使用情況。雖然類別（如“中型”和“大型”）之間的界限必然是人爲定義的，但類別之間的趨勢是明顯的。
原文鏈接：