本文基于SWOT分析法,總結Serverless目前的優劣,以及在實踐過程中可能遇到的風險與機遇。
Strengths
-
按需付費
用戶根據代碼調用的次數和運行時間計費,時長計量顆粒低至百毫秒級別,用戶只需要為代碼實際運行消耗的資源付費,代碼未運行則不產生費用
-
降低開發成本
根據Serverless提供的一系列的函數計算模板,開發者只需要填寫好服務需要的配置即可。這一系列的服務都可以自動、高效的完成
-
自動擴展能力
開發者無需關注應用的負載均衡,虛機的存儲和計算資源,應對更多請求時,Serverless會自動的擴容
Weaknesses
-
不適合長時間運行應用
Serverless 在請求到來時才運行函數,這意味著,當應用不運行的時候就會進入 “休眠狀態”,當請求再次來臨時,應用需要一個啟動時間
如果應用需要長期不間斷的運行、處理大量的請求,那么就不適合采用 Serverless 架構
-
完全依賴于第三方服務
當用戶采用 Serverless 架構的時候,就和特定的服務供應商綁定了,假如用戶使用了AWS的Serverless服務,由于兼容性問題,當他再想把應用遷移到阿里云上時,可能會增加很多額外的成本
-
配置復雜
根據很多實踐過Serverless架構的工程師反映,Serverless的配置相當復雜,在試驗時需要進行很多繁雜的配置,更別提生產環境的復雜程度了
Opportunities
-
云廠商的大力支持
近幾年隨著Serverless架構的興起,越來越多的云廠商提供了FaaS(Function as a service)的解決方案
-
豐富的實踐
很多知名公司都開始嘗試使用Serverless,如新浪微博、石墨文檔、芒果TV等,相信Serverless會被更多的企業接受
Threats
-
數據安全性
使用Serverless架構,大量的數據需要部署在公有云上,數據的隱私和安全性存在一定風險
-
服務的穩定性
使用Serverless架構,意味著應用嚴重依賴于特定的云平臺和第三方服務,如果要做多云融合可能會遇到更復雜的問題
-
兼容性
在有基礎設施的條件下,OpenStack提供的Serverless方案Qinling無法與第三方服務商的方案兼容,這又回到了上一個問題,即應用嚴重依賴于特定的云平臺
以上,僅供參考