PaaS、CaaS還是FaaS？該如何選擇？

Isaac Sacolick

想象一下，走進一家專門經營漢堡包的商店，里面有各式各樣的漢堡包。雖然店里只有漢堡包，但是當你想購買漢堡包時，那么這家商店可提供的選擇還是很多的。

如果你是漢堡包達人，那么你可以在第一通道自己挑選牛肉、雞肉、奶酪、面包、蔬菜、調味品以及其他制作漢堡包可能要用到的配料。你甚至還可以選擇用于盛餐的盤子和容器。

如果你沒有時間、手藝或興趣自己制作漢堡包，那么你可去第二通道，并在那里購買一個漢堡包。除了經典款外，你還可以選擇有機漢堡、素漢堡、甚至是生酮keto漢堡。你只需要按照說明進行操作，就可以吃上一個美味的漢堡。

如果你是漢堡包廚師，那么老板可能會打來電話，讓你在午餐前的兩個小時內制作300個不同類型的漢堡。除了制作漢堡之外，你還必須要招呼客人并負責收款。在這期間，你必須要小心，因為有些人對漢堡包會有一些特殊的要求，還有一些人則會插隊并偷走他們的午餐。

最后，在午餐期間你會遇到健康和安全檢查，因此無論你做什么都應嚴格遵守規定。遺憾的是，和你一起工作的只有幾個人，并且他們在這些方面幾乎沒有什么經驗。

制作“云”漢堡

選擇云架構非常類似于上述制作漢堡包的操作，并且在許多方面要更為復雜。在選擇使用哪個云架構時，開發人員、工程師、架構師和IT領導者需要考慮平臺、性能、法規和其他因素。

哪種架構可為客戶提供更好的體驗和更高質量的產品呢？哪個更易于操作并能按期完成呢？哪條路徑可以更好地處理支持性、合規性和安全性問題呢？最后，哪種方法是你能夠以最低的成本部署的呢？

工程技術人員可以選擇“容器即服務”（CaaS），并對應用程序進行容器化。這相當于廚師通過第一通道自己制作漢堡。如果他們不具備這些專業知識，那么平臺即服務（PaaS）相當于在第二通道，他們可以選擇套件并遵循使用指導和限制。

那CaaS和PaaS都不符合需求呢？那也好辦，你可以從頭開始構建所有內容（基礎設施即服務或IaaS），也可以將函數部署到無服務器環境（也就是函數即服務或FaaS）。

FaaS是一種無服務器計算，旨在響應單個任務。例如，FaaS可用于驗證用戶身份，對正文進行拼寫檢查或進行數學計算。

顯然，將代碼托管、配置、管理或部署到云端有許多選項。在考慮不同的產品解決方案時，事情往往會變得非常復雜。PaaS選項包括Azure應用服務、AWS Elastic Beanstalk、谷歌App Engine、Red Hat OpenShift和Salesforce的Heroku等。如果你正在考慮CaaS解決方案，那么你會發現亞馬遜、谷歌和微軟都擁有自己的托管Kubernetes服務，它們分別為EKS、GKE和AKS。此外，你還可以選擇來自VMware、IBM、甲骨文、Rackspace等廠商的產品。

當然，你還有更多的無服務器選項。Azure Serverless擁有無服務器函數、Kubernetes Pod和應用程序環境。AWS的無服務器選項則較為廣泛，并涉及計算、存儲、數據倉庫、API代理等的功能類別。谷歌Cloud對無服務器進行了廣泛的定義，其中包含了BigQuery和AutoML等服務。

關于CaaS、PaaS、FaaS和無服務器的關鍵注意事項

在評估不同的云體系結構時，需要注意以下一些事項。

目標受眾——PaaS和FaaS選項的優先目標是開發人員，他們使得解決方案更易于配置且可與CI/CD（持續集成/持續交付）管道整合在一起進行部署。容器參數化了操作環境和平臺配置，因此這些工具的目標通常是操作人員和系統管理員。

可配置性vs敏捷性——通常，CaaS的可配置性最高。在容器化方面，CaaS在平臺和配置的選擇上賦予了操作人員極大的靈活性。PaaS和FaaS則更專注于敏捷性，能夠幫助開發人員更快地部署和測試代碼。

已經過優化的PaaS解決方案——如果PaaS和FaaS解決方案經過了預先優化，那么這意味著你已被平臺和配置選項所鎖定。這些解決方案是根據設計師的意見開發的，這些設計師決定了開發人員的需求、最佳實踐和目標性能特征。對于那些喜歡更高的靈活性或更多控制權的操作人員而言，這種自以為是的PaaS或FaaS會讓他們感到束手束腳。

技能和學習曲線——通常情況下，與PaaS和FaaS解決方案相比，CaaS解決方案的學習曲線更加陡峭，并且需要更多的技能。

廠商鎖定——CaaS解決方案通常都是基于Kubernetes開發的，并且可以在不同的云托管服務商之間遷移。盡管PaaS和FaaS解決方案也可以以Kubernetes為基礎進行設計，但是他們一般不會向最終用戶開放Kubernetes層，取而代之的是提供更為簡潔的配置。這些配置為PaaS和FaaS解決方案所專有，并且通常被設計為僅在某個云端上運行。一些IT主管發現了這個問題，并擔心會被云服務提供商鎖定。

一些關于研究和原型制作的問題

當面對如此多的選擇時，一些企業幾乎不再進行研究和原型制作，而是選擇走捷徑。還有一些企業依然投入大量的時間、精力和資金來研究可供選擇的選項，咨詢專家意見，然后再選擇可以實現可靠部署的選項。

當面臨太多選擇時，企業往往會變得不知所措，相比之下，這兩種做法反而效果更好。在當今的快節奏世界中，所有的企業都在試圖獲取技術優勢，過于保守和維持現狀只會抑制企業的發展機會。

因此，我咨詢了許多專家并找出了一些關鍵問題。這些問題可以幫助企業縮小選擇范圍：

1.你是否有一支只負責少量應用程序的小型團隊？在這種情況下，你應該考慮使用更為簡單的PaaS和無服務器。優點是，用戶無需投入大量的時間和專業知識就可以獲得大多數自己所需要的且經過預配置過的平臺。AvidXchange平臺架構總監DJ Navarrete建議：“對于那些需要調整大量管理措施提供支持的中小型企業，以及那些希望迅速提高成熟度、穩定性和速度的企業而言，PaaS之所以具有吸引力是因為它們為部署和提高效率提供了一條更為快捷的途徑。”

2.你是否有一些在有需求時才需擴展的暫時性負載？如果答案是肯定的，那么除了完整的應用程序和數據庫外，你還可以選擇使用微服務或函數。這些用例非常適合無服務器計算，你只需為所需的使用量付費即可。

3.你是否有合規義務或是受到一些法規標準的約束，強制你要對執行容器、應用程序、數據庫、操作系統或基礎設施中的某些特定的基礎性選項或設置進行報告？微軟Modern Workplace卓越中心的安全與合規架構師Wayne Anderson指出，這是排除無服務器選項的一個重要原因。PCI和其他合規性要求通常被法律部門或審核人員理解為需要計算環境設置的證明。

4.你是否正在使用許多專用平臺或舊版應用程序？在這些情況下，你可能很難找到兼容的商用PaaS選項。與此同時，容器的開發可以簡化部署和依賴性管理。

5.你的企業是否是一家使用著多個云服務，并在生產中使用各種應用程序和數據平臺的大型公司或企業？這些公司可選擇對容器進行標準化，因為它們在支持多個平臺和配置選項方面能夠提供最大程度的靈活性。如果合規性不是一個因素，那么你可以考慮無服務器。如果企業具有足夠的技術實力，且能夠基于Kubernetes開發出更多的選項，那么企業要避免PaaS。擁有足夠規模和技術實力的企業（例如Shopify）可以選擇以Kubernetes和容器為基礎設計自己的PaaS。

6.你是否正在開發微服務并在基于云的微服務架構上進行標準化？Mark Heath認為，在這種情況下，容器或FaaS都是不錯的選擇，在容器中托管函數也是如此。Heath表示，無服務器函數更容易配置且支持成本更低，而容器則可以簡化本地開發并為保護端點提供更多選項。

7.云服務顧問Sarbjeet Johal想知道，你是正在構建平臺，應用程序還是服務，以及受眾是企業內部的，外部的，還是面向客戶的，亦或是機器消耗品？了解應用程序的類型和最終用戶的類型有助于預測未來的需求。Johal舉例說：“對于外部應用程序，你想要記錄更多的訪問控制，那么數據量可能會出現意外增長，與內部應用程序相比，該應用程序的壽命可能會更長。如果一個服務或平臺是機器消耗品，那么你可能需要計量。”對路線圖和未來需求進行預測可以幫助選擇某些選項，并排除其他的選項。

一旦縮小了選擇的范圍，最佳實踐將是進行概念驗證。就如同在不確認訂單的情況下，你是不會制作300個漢堡包的。

本文作者Isaac Sacolick為《驅動數字技術：通過技術實現業務轉型的領導者指南》一書的作者。該指南介紹了許多關于敏捷性、devops和數據科學的實踐，對成功的數字化轉型計劃具有重要的指導意義。

原文網址

https：//www.infoworld.com/article/3531270/paas-caas-or-faas-how-to-choose.html