選擇Serverless還是Kubernetes?這種爭辯並沒有意義
Kubernetes和Serverless都是令人興奮的強大的平臺,它們可以通過多種方式為企業在敏捷性,擴充套件性以及計算效能上獲取巨大的提升。但是,不要忘記Kubernetes能提供一些Serverless所沒有的功能,反之亦然。成功部署其中任何一個方案的關鍵點在於哪種技術更適用於當前的場景。
Kubernetes的興起
Kubernetes是為大規模的雲端計算設計的,一開始就是因為Google使用了超大規模的部署才開發了Kubernetes。之後Kubernetes被改造成可以小規模使用,並且適用於大多數大型雲提供商,這歸功於它過去幾年迅猛的發展。根據Cloud Native Computing Foundation(CNCF)的使用者調查,Kubernetes的增長遠超過所有其他形式的編排軟體。
自首次亮相以來,Kubernetes已成為主流。但是,正如從主機遷移到客戶端伺服器上總會遇到各種問題,在採用完全基於容器架構的過程中也依然會遇到各種問題,儘管這種容器架構是由Kubernetes進行編排的。容器擴充套件並不是實時的,你需要等到容器上線,同時你也必須處理容器管理問題。據CNCF調查表明,儲存,安全以及網路問題仍然是通過Kubernetes部署其架構的程式設計師最關心的問題。
那麼選擇Serverless呢?
Serverless架構,在很多方面只是對微服務架構的重新打包和重新構想,這種架構正在與Kubernetes形成競爭,因為它允許擴充套件應用程式和部署,無需擔心複雜性和配置問題。這兩個問題正是使用Kubernetes和容器的痛點。 但不要把兩者當做一樣的。
Serverless也被稱為功能即服務(FaaS),Serverless體系結構仍然需要執行伺服器,但是它是事件驅動的架構,相比之下,容器化應用程式本質上仍然是傳統的應用程式,只是分成許多較小的部分或服務。
使用容器化的應用程式,它永遠不會完全關閉。即使沒有人訪問它,容器仍然需要存在並執行。你可以將它們縮小到單個例項,但它們仍在執行並需要花錢。
一個Serverless應用,如果沒有請求使用它的功能,那麼它的成本可能降低到零,實際上如果沒有請求,它們會停止執行,這可以顯著的降低成本,並且有利於更迅速的伸縮。訪問Serverless程式的請求越多,它的體量就會變得越大。
關於Serverless架構會取代容器化的應用程式的想法似乎是一個不合理的建議,並非一切功能都能被簡化成一個短暫的功能(function)。一些程式需要在應用程式執行時持久化資料以及狀態,Serverless的設計很難滿足這種需求,但是大家對Serverless的興趣卻在快速增長。
例如,根據MarketsandMarkets Research的資料,FaaS(Function as a Service)市場預計將從2016年的1.88美元飆升至2021年的77.2億美元。
然而,這不是一場零和博弈(即參與遊戲的個體必須通過其他個體的損失來獲益,所有個體不能同時獲益或者損失),而Serverless的增長並不一定預示著Kubernetes和容器的死亡。實際上,它甚至可能幫助擴充套件Kubernetes的使用,至少可以通過主要的FaaS提供商來擴充套件其Serverless產品。
Serverless架構很可能通過僅僅支付使用的服務而不用支付執行容器或一組容器所需的開銷來進一步降低成本,但是這件事需要進行權衡,不經常訪問的Serverless程式碼雖然執行成本不高,但在執行時(如Java)或底層容器用於服務請求的情況下,可能會遇到延遲增加的問題。這些額外的延遲可能令人無法接受。
從一個開發者的角度來說,FaaS可以極大的促進效率的提升,使程式設計師的開發過程更加愉悅,程式設計師可以更快的將小塊程式碼推到生產環境而不用顧慮配置和管理的開銷,從而提高生產力。
結論
應用程式開發和部署策略,都在不斷髮展。通常,從一個架構到另一個架構的遷移標誌著第一個架構的終結,但情況並非總是如此。至少現在,還沒有一個通用的解決方案可以解決低成本的,大規模的交付應用程式所遇到的所有問題。與任何部署模型一樣,架構師需要在成本,效能和可管理性之間進行權衡。
Kubernetes——以及其他的容器化技術——已經擁有了它們應得的地位,Kubernetes市場的迅速普及和發展證明了它正滿足市場需求。雖然我並沒看出容器化的必要性,如果不必要,那麼容器編排也沒任何意義,這種解決方案也並總是適用。
同樣Serverless的FaaS顯然填補了市場的需求,並且整體上呈現出顯著的增長。當然,增長並不一定意味著合適,但市場傾向於自我糾正以彌補這一點。
同樣,Kubernetes vs.Serverless不是零和博弈。Serverless的增長並不表示Kubernetes的死亡。每個技術在現代應用程式的開發和部署中都發揮著重要作用。在過去的20年中,應用程式部署一直朝著更小,更易管理,更具成本效益和開發人員友好的架構邁進,並且毋庸置疑這種趨勢會持續下去。雖然Serverless可能是將應用程式抽象到其最基本元件的邏輯結論,但並非所有應用程式都能以這種方式抽象出來。同理可得,出於對永續性和可伸縮性的需求,某些應用程式將會需要容器,需要容器的編排和管理。
如果這兩種技術沒有直接相互競爭,它們很難不會有持續性的顯著增長。
本文轉自DockOne-選擇Serverless還是Kubernetes?這種爭辯並沒有意義
相關文章
- 獨享還是共享,你選擇哪一種鎖?
- 一個40歲老碼農的總結,奮鬥沒有意義,選擇大於努力
- HTM - JSX 的替代品?還是另一種選擇?JS
- HTM – JSX 的替代品?還是另一種選擇?JS
- 如何給玩家“有意義的選擇”? “選項”設計的3條原則
- CDPR 如何設計《巫師 3》中那些富有意義的選擇?
- 選擇HTTPS代理還是SOCKS代理?HTTP
- 選擇python還是web前端好PythonWeb前端
- 微服務選擇Spring Cloud還是Dubbo?微服務SpringCloud
- 選擇 Python3.6 還是 Python 3.7Python
- 你應該選擇 Ubuntu 還是 Fedora?Ubuntu
- iOS 開發選擇OC還是Swift?iOSSwift
- Java選擇自學還是培訓?Java
- 是列舉?還是常量?其實很好選擇!
- Serverless 選型:深度解讀 Serverless 架構及平臺選擇Server架構
- WEB 版的報表工具有沒有意義?Web
- 如何判斷FMEA的存在是否還有意義?
- 如何選擇谷歌seo還是adwords廣告?谷歌
- workman還是swoole,大家選擇那個呢?
- 分析選擇Salesforce CRM還是Zoho CRM(上)Salesforce
- Serverless Kubernetes 和 Serverless on Kubernetes 的區別Server
- Python初學者,選擇Python2還是選擇Python3好?Python
- 寫年終總結到底有沒有意義?
- IBM AI辯手對戰世界級人類辯手,炒作還是秀肌肉?IBMAI
- 為什麼說內鏈優化對網站排名還是有意義的優化網站
- 模切企業是選擇成長中ERP還是選擇成熟度高的ERP?
- web伺服器該選擇apache還是nginxWeb伺服器ApacheNginx
- API架構的選擇,RESTful、GraphQL還是gRPCAPI架構RESTRPC
- 小程式還是APP,企業該如何選擇?APP
- 都 9012了,該選擇 Angular、React,還是Vue?AngularReactVue
- Word2Vec究竟選擇Tensorflow還是gensim
- 企業選擇Salesforce CRM還是Zoho CRM(下)Salesforce
- OpenStack並沒有被Kubernetes替代 - mirantis
- 自定義周選擇元件、年選擇元件元件
- 一個很有意思的選擇表情DialogActivity
- Kubernetes – 標籤和選擇器
- element ui 自定義的快捷選項的日期選擇器並格式化UI
- netty系列之:選byte還是選message?這是一個問題Netty