使用率激增250%，这份报告再次将 Serverless 推向幕前
向幕前
作者 | 望宸
本文是對 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 建模類的應用。
觀點三：除 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/
原文鏈接：https://developer.aliyun.com/article/784696?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的使用率激增250%，这份报告再次将 Serverless 推向幕前的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 2021阿里巴巴研发效能峰会来啦！
- 下一篇： “‘天池·TEENTOP杯’AI少年挑战