作者 | 望宸
本文是對 Datadog 最新的一份 Serverless 報告的解讀，歡迎大家留言讨論。
每項新技術的産生和演進過程中，都會有他自己的擁趸，也會有持懷疑論者。Serverless 的美在于他可以盡可能的解放客戶在基礎設施上的投入，隻需專注于自己的業務，讓技術産生更多商業價值，同時，客戶隻需要真正為使用量付費，無須讓計算資源常駐。
“Datadog 上一半的 AWS 客戶使用了 Lambda，80% 的 AWS 容器客戶使用了 Lambda。”
是的，這個資料來自 Datadog 去年的一份調研報告，客觀反映了 Serverless 在海外市場的落地程序。一年之後，Datadog 釋出了第二份 Serverless 調研報告，我們來一起看看 Serverless 在海外的最新進展，這對于無論是已經投入建設 Serverless，還是仍處于觀望狀态的決策者和使用者而言，也許都能獲得一些參考。
觀點一：Lambda 的調用頻率比兩年前高 3.5 倍，運作時長達 900 小時 / 天
Serverless 的使用深度如何來定義？
自 2019 年以來，一直在使用 Lambda 的企業已大大提高了其使用率。平均而言，到 2021 年初，這些公司每天調用函數的次數是兩年前的 3.5 倍。此外，在同一組 Lambda 使用者中，每家企業的功能平均每天平均運作達 900 個小時。
普通雲伺服器，是按伺服器的租用配置和租用時長進行收費的，其中，租用配置是依據 vCPU 和記憶體定價。
而函數計算則不同，按使用過程中的調用次數和函數運作時長收費的。是以，調用次數和函數運作時長是衡量客戶使用 Serverless 深度的名額。報告中未提供每天調用次數絕對值的資訊，但我們可以依據每天運作 900 小時運作時長的資料，對客戶在 Serverless 的消費做一個區間預估。
以阿裡雲函數計算的收費标準來計算，使用預付費模式：
每 1 GB 計算力的執行個體運作 1 秒所需的費用是 0.00003167 元，以記憶體規格 1GB，每天運作 900 小時來計算，預計将消費 102.6 元，年度消費是 3.7 萬，再搭上存儲、網絡、安全、資料庫等其他雲産品的消費，已經是一個中型企業的雲上支出了。此外，函數的調用次數所産生的費用通常不會太多，尤其是 Python 這類和 AI 模組化相關的函數應用，阿裡雲函數計算每天調用 100 萬次的費用是 13.3 元。
觀點二：Lambda 執行時長的中位數是 60 毫秒，僅為一年前的一半
事件驅動架構下，執行時長是一個關鍵生産因素
函數的執行時長是 FaaS 領域的新概念，因為 FaaS 是事件驅動架構，實際觸發時，才會調用計算資源執行函數應用并進行計費，函數應用執行時間越長，費用就會越高。不同于函數計算，普通雲伺服器則是按租用伺服器來計費，雖然普通雲伺服器也提供自動彈性伸縮的功能，但由于本身不是事件驅動架構，導緻伸縮規則上是受限的，而且，普通雲伺服器是按秒計費，而業内的 FaaS 産品，例如 Lambda、阿裡雲函數計算都已經支援按毫秒計費，計費顆粒度越細，計算成本的優化空間就越大。
從資料結構上我們可以看到，越來越多的 AWS 客戶正在遵循官方提供的成本優化最佳實踐，來縮短函數的執行時長，進而進一步優化計算成本，最大程度發揮 Serverless 的成本優勢。
下圖中，函數執行時長曲線的尾巴很長，這表明 Lambda 不僅支援短期作業，而且已經在支援計算密集型的用例。雖然此份報告沒有展示哪些計算密集型的業務場景使用了 Lambda，但從國内雲廠商宣傳的案例看，主要是音視訊處理、AI 模組化類的應用。
使用率激增250%，這份報告再次将 Serverless 推向幕前 使用率激增250%，這份報告再次将 Serverless 推向幕前
觀點三：除 AWS Lambda 外，Azure Function 和 Google Cloud Function 的增長也很迅速
百家齊放是行業走向成熟的必經階段
AWS Lambda 是最早的 FaaS 産品，Azure 和 Google 緊随其後，推出了 FaaS 産品，他們的增速可能得益于整個行業的成熟度，從一年前隻有 20% 的 Azure 客戶使用 Azure Function，一年後，這一資料已經增長到了 36%，而 Google 已經有 25% 的雲上客戶在使用 Cloud Function 了。
該部分，報告中引用了 Vercel 這個案例：
Vercel 是一個很實用的網站管理和托管工具，可以快速部署網站、App，甚至不需要購買伺服器、域名、安裝與配置 Nginx、上傳網站檔案、添加 DNS 解析項、配置網頁證書，最重要的是個人使用是永久免費。
Vercel 托管的都是一些耦合度不高的應用。很顯然， Vercel 的這一商業模式充分利用了 Serverless 技術的成本優勢，來盡可能降低免費個人使用者帶來的伺服器成本，通過函數應用來處理來自服務端渲染、API 路由等的請求。在過去的一年裡，Vercel 每月的伺服器調用次數從 2.62 億次增加到每月 74 億次，增長了 28 倍。
Vercel 官網：
https://vercel.com/觀點四：AWS Step Functions 是 Lambda 的最佳伴侶，平均每個工作流包含 4 個函數，并逐月上升
函數應用的編排功能正在拓展函數應用的邊界
一個完整的業務邏輯通常不是一個函數應用就能完成的，需要用到多個函數應用，甚至還涉及到彈性計算、批量計算等計算單元。這時候，通過工作流的編排能力，對各個計算任務進行順序、分支、并行等方式的分布式編排，可以簡化繁瑣的業務拼接帶來的代碼工作，還能可視化監控整個業務流程中各個執行環節的狀态，一舉兩得。AWS Step Functions 就提供了這樣的功能。
報告顯示，平均每個 Step Functions 工作流包含 4 個 Lambda 函數，并且呈現逐月增長的趨勢。說明越來越的客戶正使用工作流來處理越來越複雜的業務邏輯。其中，執行時間在 1 分鐘内的工作流占比 40%，但也不乏一些執行時長多于 1 小時甚至超過 1 天的工作流，這些長時間執行的工作流以 AI 模組化為主。
該部分，報告中引用了 Stedi 這一案例，這家企業是在 B2B 交易的交易領域提供結構化消息發送的服務，例如營銷郵件的推送等服務，這類業務場景具備事件觸發、短時間需要調用海量目标郵箱郵箱的特點，Serverless + 工作流就可以很好的滿足了客戶在成本和開發運維效率上進行優化的訴求。
Stedi 官網：
https://www.stedi.com/觀點五：四分之一的 AWS CluodFront 客戶使用 Lambda @Edge
邊緣正成為 Serverless 的新市場
Lambda@Edge 是 Amazon CloudFront 的一個功能，它可讓客戶在靠近應用程式使用者的地方運作代碼，進而提高性能，降低延遲。使用 Lambda@Edge，客戶無需在全球多個地方預置或管理基礎設施，隻需按使用的計算時間付費，代碼未運作時不産生費用。
相當于在邊緣的場景下，網絡将 Serverless 的計算能力一起提供給客戶，而無須從雲端調用算力，提高了那些對延遲敏感的邊緣業務的客戶體驗，例如物聯網場景下視訊監控和智能分析、業務監測和分析等任務。
報告顯示，四分之一的 Amazon CloudFront 客戶使用了 Lambda@Edge，其中 67% 的客戶的函數執行時長不到 20 毫秒，說明這部分應用對延遲非常敏感，這類的邊緣業務需求越多，Serverless 在邊緣端的潛力就越大。
觀點六：超過一半的客戶函數預留執行個體的資源使用率不到 80%
冷啟動是事件驅動架構下一個無法回避的命題
尤其是在 Java/.Net 的程式設計架構下，應用的啟動會更慢，因為 Java 需要初始化其虛拟機 (JVM) ，并将大量類加載到記憶體中，然後才能執行使用者代碼。業内提供了很多優化冷啟動的思路，例如提供函數預留執行個體，或者通過按需加載和更高效的存儲和算法來提升容器鏡像的拉取速度，進而優化冷啟動速度。
本質上講，函數預留執行個體是避免冷啟動的一個見效很快的方式，但他并沒有從根本上解決冷啟動的問題，資源預留的越多，浪費的就越多，這和 Serverless 主張的按需使用是背道而馳的。是以，今年的報告非常關注客戶在函數預留執行個體的使用率情況。
報告顯示，57% 使用函數預留執行個體的客戶用了不到預留執行個體中 80% 的資源，其中，超過 30% 的客戶僅用了不到 40% 的資源；使用率達 80%-100% 的客戶超過 40%，那麼這部分客戶應當仍然會遇到冷啟動的問題。是以，不斷優化業務的預留執行個體設計仍是廠商和客戶需要共同面對的命題，相關的最佳實踐會有較高的指導意義。感興趣的朋友可以看看阿裡雲函數計算的這份
最佳實踐。
觀點七：開源無伺服器架構是部署函數應用的主要方式
應用拆的越細，部署難度越大
Serverless 架構下，手動部署幾個函數應用可能不太複雜，一旦當應用擴充到幾十、幾百個的時候，應用的部署難度就會被成倍放大，此時通過一些部署工具來部署，可以提高部署效率。正如 Kubernetes 是用來自動部署、擴充和管理容器化應用程式的，在管理容器的過程，Kubernetes 已經是必不可少的工具。
報告顯示，80% 以上的客戶使用 Serverless Framework 來部署和管理函數應用，雖然報告未給出原因，但大體離不開 Serverless Framework 的易用性、開放性和社群屬性，報告預計基礎設施即代碼類的部署工具在大規模部署無伺服器應用程式方面将扮演更重要的角色，AWS 自研的三個部署工具，vanilla CloudFormation、AWS CDK 和 AWS SAM 的使用率分别是 19%、18% 和 13%。（存在同一個客戶同時使用兩個或多個工具，是以使用率疊加後高于 100%）
回到國内，阿裡雲、百度雲、華為雲、騰訊雲均提供了自家閉源的部署工具，騰訊雲和 Serverless Framework 合作，開發了 Serverless 應用中心，阿裡雲則是在去年開源了 Serverless Devs，提供函數應用的部署、運維和監控，此外，國内另一款提供 Node.js 開發态架構的開源項目 Midway，已經獲得 4k+ 的 star，相信随着參與 Serverless 的開發者的增加，國内開源工具生态會越發活躍。
觀點八：Python 是最流行的 Lambda 運作時，尤其是在大型環境中
Serverless 天然支援多語言的開發架構。那麼問題也來了，哪類程式設計語言最為流行呢？
報告顯示，58% 的使用者使用 Python，Node.js 則占據了 31% 的份額，Java、Go、.NET Core 和 Ruby 的份額均未超過 10%。但考慮到不同廠商各自的特點，阿裡雲上的 Java 份額可能會更高些，Azure 上 .NET 的客戶會更多些。
有趣的是，在小型的 Lambda 運作環境中，Node.js 的份額高于 Python，随着函數規模的增長，Python 就越來越流行，而在企業級組織中，Python 的使用頻率是 Node.js 的 4 倍，如下圖：
雷卷在阿裡雲内網分享了報告中程式設計語言部分的分析：大型企業在大資料、AI 等方面，使用 Python 比較多，而且他們使用的 Lambda 量也比較大，是以在 Lambda 的數量上 Python 有絕對的優勢；Node.js 應用用不了那麼大的運作期 (多核 CPU 和大記憶體），通常都是小型執行個體，另外可能是個人的 Node.js 開發者，通常也會選擇小型的 Lambda 環境。
此外，各類程式設計語言的版本的使用分布如下，依次遞減，Python 3.x、Node.js 12、Node.js 10、Python 2.7、Java 8、Go 1.x、.NET Core 2.1、.NET Core 3.1。
總結
整體上，相比去年，國外 Serverless 的使用群體在迅速擴大，函數執行時長不斷增加，使用方式也越加成熟，開發者工具也更佳開放。在國内，Serverless 已經不在局限一些離線任務或低耦合性應用，已經有不少企業客戶将 Serverless 應用于生産環節的核心鍊路上，例如世紀聯華将交易系統、會員系統、庫存系統、背景系統和促銷子產品等核心應用均部署在函數計算上，來減輕客戶在基礎設施上的投入；閑魚已經開始實踐對傳統巨型應用的 Serverless 化改造，去攻克在 Functions 之間代碼複用、對函數的依賴做統一更新等業内難題。應用的改造需要時間和視窗期，相信會有越來越的企業客戶選擇 Serverless 來解放雙手。
英文報告連結：
https://www.datadoghq.com/state-of-serverless/