Kubernetes vs. Serverless並非零和遊戲?
作為令人興奮和強大的平臺,Kubernetes和Serverless完全配得上現在的地位。它們可以通過多種方式為組織提供敏捷性、可擴充套件性和計算效能方面的巨大提升。但是,我們很容易忘記Kubernetes提供了Serverless所沒有的優勢,反之亦然。成功部署兩者的關鍵是知道何時以及如何確定Kubernetes或Serverless是否提供最佳匹配。
Kubernetes
Kubernetes本身就是為雲規模的計算而設計的 ,就像谷歌那樣的大規模部署。它已被改編為可以小規模使用,現在大多數大型雲提供商都提供該服務——這可以解釋Kubernetes在過去幾年中的爆炸性增長。根據CNCF的使用者調查,Kubernetes的增長遠遠超過了所有其他形式的編排軟體。
Kubernetes已成為主流。但正如從大型機轉移到客戶端伺服器一樣痛苦,採用完全基於容器的架構仍然存在重大痛點,即使是由Kubernetes編排的架構。擴充套件不是即時的——你必須等待容器上線,而且仍然存在重大的管理問題。根據CNCF,儲存、安全和網路問題是通過Kubernetes部署其架構的人們最關注的問題。
Serverless
Serverless架構(在很多方面只是對微服務架構的重新打包和重新映象),正在與Kubernetes競爭,因為它允許擴充套件應用程式和部署,而不會出現Kubernetes甚至容器的複雜性和配置問題。
功能即服務(FaaS)Serverless架構仍然需要伺服器來執行,更是事件驅動的架構,而容器化應用程式本質上仍然是相當傳統的應用程式,只是分成許多較小的部分或服務。使用容器化應用程式,它永遠不會完全關閉。即使沒有人訪問它,容器仍然需要存在並執行。你可以將它們縮小到單個例項,但它們仍然存在並仍然需要成本。
Serverless應用程式,如果沒有任何功能請求,可以將成本降低到零。除非明確訪問它們,否則它們基本上不再存在。這可以顯著降低成本,並且縮放速度也更快。對Serverless應用程式的訪問越多,它就擴充套件得越大。
但Serverless架構將取代容器化應用程式的想法並不合理。並非一切都可以簡化為短暫的功能。某些應用程式總是需要能夠在一個應用程式執行時保持資料和狀態,而這不是Serverless架構的設計目的。
不過,對Serverless的興趣卻在快速增長。根據MarketsandMarkets Research的資料,FaaS市場預計將從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可能是將應用程式抽象到其最基本元件的邏輯結論,但並非所有應用程式都能以這種方式提供。與此同時,由於永續性或可擴充套件性的原因,某些應用程式需要容器,需要編排和管理。
所以說,這兩種技術都沒有理由不繼續顯著增長。