使用率激增250%，這份報告再次將 Serverless 推向幕前

簡介：相比去年，國外 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 架構下，手動部署幾個函數應用可能不太複雜，一旦當應用擴展到幾10、幾百個的時候，應用的部署難度就會被成倍放大，此時經過一些部署工具來部署，能夠提升部署效率。正如 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 十二、Node.js 十、Python 2.七、Java 八、Go 1.x、.NET Core 2.一、.NET Core 3.1。

總結  

總體上，相比去年，國外 Serverless 的使用羣體在迅速擴大，函數執行時長不斷增長，使用方式也越加成熟，開發者工具也更佳開放。在國內，Serverless 已經不在侷限一些離線任務或低耦合性應用，已經有很多企業客戶將 Serverless 應用於生產環節的核心鏈路上，例如世紀聯華將交易系統、會員系統、庫存系統、後臺系統和促銷模塊等核心應用均部署在函數計算上，來減輕客戶在基礎設施上的投入；閒魚已經開始實踐對傳統巨型應用的 Serverless 化改造，去攻克在 Functions 之間代碼複用、對函數的依賴作統一升級等業內難題。應用的改造須要時間和窗口期，相信會有愈來愈的企業客戶選擇 Serverless 來解放雙手。

英文報告連接：https://www.datadoghq.com/state-of-serverless/

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。