2019年 Severless 應用報告:三分之二的落地實踐都成功了?

Gartner 報告表明:到 2020 年,全球將有 20% 的企業部署Serverless架構。同時,很多大型廠商,例如亞馬遜、微軟和谷歌等都看好Serverless領域,並投入了大量的資金。那麼,2019年Serverless的應用情況到底如何呢?

近日,O’Reilly針對Serverless的應用情況進行了首次調查。本次調查共採訪了來自不同國家、地區的1500多名開發者,這其中有使用Serverless不到一年的新手開發者,也有三年以上的資深開發者,所以調查得出的結論可以在一定程度上呈現Serverless目前的應用情況。

哪些行業、哪些崗位的人在應用Serverless?

從上圖來看,探索和使用Serverless的人並不侷限於某個單一的崗位或角色。這表明軟件團隊在逐漸轉向承擔更多的基礎架構的責任,並且選擇使用Serverless來支持。

本次調查超過五分之一的受訪者是來自軟件行業的,其次來自金融和銀行業的。軟件行業的開發者關注和應用Serverless似乎是理所當然的事情,而金融和銀行行業關注Serverless,主要是因爲其垂直領域出現了越來越多的金融科技初創企業,它們承擔了傳統基礎架構的責任,並且以更開放的心態,接納和擁抱Serverless。

應用Serverless的企業規模如何呢?根據調查結果顯示,只有三分之一的受訪者在規模小於100人的公司工作,其中企業規模大於10000人的受訪者佔據了差不多五分之一的份額。這也在一定程度上表明,目前關注Serverless的不僅是沒有技術債務或管理費用的初創公司,大型企業也很重視Severless。

企業如何應用Serverless?

目前Serverless的實際使用情況如何呢?本來以爲Serverless作爲一項比較新的技術,落地情況可能不太樂觀,但有趣的是,40%的受訪者表示他們已經採用了Serverless,這個結果完全出乎意料。

如果在細分的話,超過50%的受訪者已經採用Serverless 1-3年的時間,還有15%的受訪者採用Serverless超過了3年的時間。要知道,截止到今年11月,Amazon推出的AWS Lambda功能只有5年的歷史,應用經驗超過3年的Serverless開發者實際上就是非常早的採用者了。

另外,我們發現在過去一年中採用Serverless的受訪者有30%,這說明有相當一部分的開發者(20%的受訪者採用Serverless的時間在2-3年)在比較早的時期就已經在嘗試和採用Serverless了。有人認爲:“Serverless的興起與 Next Architecture 的趨勢是相吻合的。”所以,在未來的12-18個月內,Next Architecture的幾大重要組成部分,如分佈式、容器、雲、Serverless等都將實現可觀的增長。

目前Serverless的落地情況如何?超過三分之二的受訪者表示他們的組織大部分的Serverless落地都是成功的,他們表示:“Serverless已經超越‘炒熱度’的階段,已經成爲了一種實際可行的基礎架構選擇。”

Serverless的落地成功率如何?根據調查結果顯示,如果是擁有Serverless三年以上經驗的開發者,大約有79%是成功的,如果是一年到三年工作經驗的開發者,大約有75%是成功的,而如果是經驗不足一年的新手開發者,只有50%左右是成功的。這也在一定程度上說明應用Serverless所遇到的工具、數據和操作難題需要經驗來解決。

爲什麼要採用Serverless呢?首先,“減少運營成本”是大家採用Serverless的第一大原因,應用Serverless之後,就無需爲潛在的流量高峯購買大部分時間處於空閒狀態的服務器機架;第二,“自動按需擴展”,採用Serverless之後,可以隨時擴展到當前的使用量,消除了意外或者季節性流量高峯的困擾;第三是“無服務器維護”,由於企業中大部分開發人員都是軟件工程師,並不是系統管理員,所以對於軟件的修復、保護和管理並不擅長,而使用Serverless之後,這些工作都可以交給供應商,他們只需專注於軟件開發。

現在應用Serverless存在哪些挑戰呢?

首先,教育和培訓現有員工。由於Serverless還是一個比較新的技術,很難找到標準、正式的培訓,所以企業必須形成特定的文檔培訓員工,同時需要根據實踐案例不斷更新文檔。另外,由於Serverless還處於高速發展階段,各大供應商也在不斷推出新功能,這也給企業培訓員工增加了不少難度。

第二,“供應商鎖定”。這是一個大家都會擔心的問題,某個供應商平臺編寫的代碼是不是能夠遷移到其它平臺。由於Serverless還是一個新興市場,所以關於供應商之間的可移植性問題還處於觀察階段。

第三,集成/測試困難。對於Serverless架構而言,測試是複雜且勞動密集型的工作,需要處理更多的場景,同時因爲需要依賴項的不同,集成也是一個需要解決的問題。

Serverless的工具選型

在Serverless領域有哪些比較好的平臺和工具可選呢?根據O’Reilly的雲原生調查報告顯示,Amazon推出的Serverless產品因爲先發優勢,佔據了市場的主導地位,而微軟和谷歌也相繼推出了自己的Serverless產品,並且借勢各自的雲平臺獲得了一定的市場份額。

在使用工具的調查中,“自定義工具”佔據了首位。這說明目前缺乏一個標準化的工具來解決和管理部署到Serverless架構所遇到的問題,因此,客戶要麼是使用內部工具遷移,要麼是花費時間精力來構建定製化產品。

爲什麼有些企業不用Serverless?

前面講了很多應用Serverless的原因和方法,接下來,我們分析一下爲什麼還有企業沒有采用Serverless?

60%的受訪者表示是安全問題。因爲很多行業對於IT環境的安全性要求很高,而採用任何新技術都可能會帶來安全風險。另外,Serverless爲數據管理引入了另一種範式,使得敏感數據更加動態,企業無法更好的管理和控制這些數據,存在以下潛在的問題,例如訪問權限、訪問安全性、元數據或軟件是否已打補丁等等。

另外,還需要面臨GDPR等安全法規的挑戰,在第三方服務器的雲中,是否能夠擁有與自己基礎架構中相同級別的安全性呢?

不過,令人欣慰的是,雖然Serverless是個新技術,但是技術人員對此很感興趣,大約一半的受訪者都希望自家企業能夠在未來三年內,嘗試和落地Serverless。

Serverless的未來發展

歲末年初,對於技術的未來展望似乎是個慣例。因此,我們也採訪了阿里雲原生應用平臺高級技術專家許曉斌,他和我們分享了對於Serverless 2020年發展的預測:

Serverless 已經開始從偏離線業務進入在線業務

真正的按請求次數計費和從零到一的響應時間是一個天然的矛盾,以 FaaS 爲代表的 Serverless 技術一開始都是從對響應時間不敏感的,事件驅動的偏離線業務入手。但是今天我們已經看到,包括 AWS Lambda Provisioned Capacity 和 Azure Functions Premium plan 在內的產品特性,都在讓用戶稍微付出一點額外的成本以換取更低的響應時間。這對於在線業務來說,無疑是更適合的。

Serverless 不僅僅是應用或者函數的能力,也會加速推動基礎設施和服務 Serverless 化

業務代碼託管給 Serverless 平臺之後,即能享受到自動彈性,按請求計費能能力。但是如果基礎設施和相關服務不具備實時的擴縮容能力,那麼對於業務整體來說,就不是彈性的。我們已經看到 AWS 圍繞 Lambda 對 VPC 網絡、數據庫連接池等資源做了大量實時彈性優化,相信其他的廠商也會跟進,進而行業整體會加速基礎設施和各類雲服務的 Serverless 化。

以 Knative 爲代表的開源解決方案會得到越來越多的關注

儘管各個雲廠商都在大力推廣自己的 Serverless 產品,但是開發者普遍還是會擔心被廠商綁定,因此具備一定規模的組織會基於開源方案,如 Knative,搭建自己的 Serverless 平臺。而一旦某個開源方案成爲主流,雲廠商就會主動去兼容開源標準並增大社區投入。

期待 Java 持續進擊,成爲 Serverless 平臺主流語言之一

Serverless 平臺要求應用的鏡像足夠小以能夠快速分發,同時要求應用的啓動時間極短。雖然在這些方面,Java 和 NodeJS 和 Python 等語言有差距,但是 Java 社區在不斷努力。我們看到 Java 通過 Java 9 Modules 以及 GraalVM Native Image 等技術在不斷努力“減肥”,主流框架 Spring 也開始擁抱 GraalVM,而新的框架如 Quarkus 和 Micronaut 也在做新的突破。期待 Java 在 Serverless 領域給人煥然一新的感覺。

基於 WebAssembly(簡稱 WASM) 的 FaaS 方案有望出現

Docker 的創始人之一 Solomon Hykes 曾說,“如果2008年有 WASM 和 WASI,我們當時就沒有必要創造 Docker 了”,這句話在一定程度上說明了 WASM 的重要性。雖然當下 WASM 更多作爲一種運行在瀏覽器端的技術被人瞭解,但是它具備非常優秀的安全隔離能力,極快的啓動速度,以及對於超過20種語言的支持,那麼爲什麼不能讓它運行在服務端呢?這些技術特性都非常契合 FaaS 的要求。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章