企業在為基于容器的應用程序選擇云計算架構時需要了解關鍵問題和注意事項。

[[319047]]

想象一下，走進一家專賣漢堡包的雜貨店，里面有各種各樣的漢堡包，雖然有很多選擇，但只有漢堡包。

如果你是一名漢堡包廚師，可以在店里選擇牛肉、雞肉和其他蛋白質，以及奶酪、面包、蔬菜、調味品以及其他制作漢堡包的食材，甚至還可以選擇盛餐的盤子和容器。

如果你沒有時間、技能或興趣自己制作漢堡包，那么可以在店中購買漢堡包。除了傳統的選擇之外，還有素食漢堡包等。只需按照工具包中的說明進行操作，就可以吃到一個美味的漢堡。

如果漢堡包廚師突然得到通知，需要在午餐前的兩個小時內制作300個不同的漢堡包。另外，除了制作漢堡之外，還必須實施一個流程為客戶提供服務并獲得報酬。那么需要小心，因為有些客戶想要特殊訂單，而另一些客戶會減少訂單。

最后，在午餐期間還需要進行健康和安全檢查，因此無論做什么，都應更好地遵守規定。而你只能和幾個人一起工作，他們在這種操作上經驗也很少。

制作云漢堡

在云計算架構中進行選擇與這種臨時制作漢堡包的操作非常類似，并且在許多方面要復雜得多。在考慮要運行的云計算架構時，開發人員、工程師、架構師和IT領導者需要考慮許多平臺、性能、法規和其他考慮因素。

哪種云計算架構將為客戶提供更好的體驗并提供更高質量的產品?哪個更易于操作并在截止日期前完成?哪條路徑可以更好地處理支持、合規性和安全性問題?最后，能否以比較低的成本實施哪種方法?

工程師可以選擇容器即服務(CaaS)選項并對應用程序實施容器化，這相當于漢堡包廚師通過創建和操作餐點。如果他們不具備這些專業知識，那么平臺即服務(PaaS)選項相當于選擇工具套件并遵循使用說明和限制。

容器即服務(CaaS)和平臺即服務(PaaS)都不符合需求嗎?可以從頭開始構建所有內容，(采用基礎設施即服務)，也可以將功能部署到無服務器環境(采用功能即服務)。

功能即服務(FaaS)是一種無服務器計算，旨在響應單個任務。例如，功能即服務(FaaS)可用于驗證用戶身份、對文本體執行拼寫檢查或執行數學計算。

顯然，有許多架構選項可以托管、配置、管理和部署代碼到云平臺。考慮到不同的產品，事情變得更加復雜。PaaS選項包括Azure應用服務、AWS彈性Beanstalk、Google應用引擎、Red Hat OpenShift和Salesforce的Heroku等等。如果正在探索容器即服務(CaaS)解決方案，那么Azure、Google、AWS公司都有自己的托管Kubernetes服務，它們都有自己的縮寫(分別是EKS、GKE和AKS)。另外，還有來自VMware、IBM、Oracle、Rackspace等的其他選項。

當然，還有更多的無服務器選項。Azure Serverless具有無服務器功能，Kubernetes Pod和應用程序環境。AWS云平臺當前具有更廣泛的無服務器選項，并將其無服務器分為用于計算、存儲、數據存儲、API代理等的功能類別。Google Cloud對無服務器進行了更廣泛的定義，其中包含BigQuery和AutoML等服務。

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

審查這些不同的云計算架構時，還有一些注意事項。

• 目標受眾——平臺即服務(PaaS)和功能即服務(FaaS)選項首先通過使解決方案易于配置并與持續集成(CI)/持續交付(CID)管道集成，以進行部署來針對開發人員。容器將操作環境和平臺配置參數化，因此這些工具通常針對運營人員和系統管理員。
• 可配置性與敏捷性——通常，容器即服務(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)企業是否具有合規義務或法規標準，強制報告執行容器、應用程序、數據庫、操作系統或基礎設施中的特定基礎選項或設置?微軟公司現代工作場所卓越中心的安全和合規架構師Wayne Anderson說，這是排除無服務器選項的重要原因。法律部門或審核人員通常將PCI法規和其他合規性要求解釋為需要計算環境設置的證明。

(4)企業是否在利用許多專用平臺或遺留應用程序?在這些情況下，可能很難找到兼容的平臺即服務(PaaS)選項。同時，開發容器可以簡化部署和依賴性管理。

(5)如果是大型組織或企業，在多個云平臺中運營，并且在生產中具有各種應用程序和數據平臺，這些組織可能選擇對容器進行標準化，因為它在支持多個平臺和配置選項方面提供了比較大的靈活性。如果合規性不是一個因素，那么仍然可以考慮無服務器。如果企業具有足夠的技能和能力來開發Kubernetes上廣泛的選項，則企業可能會避開平臺即服務(PaaS)選項。具有足夠規模和技術技能的組織(例如Shopify)可以選擇以Kubernetes和容器為基礎來設計自己的平臺即服務(PaaS)。

(6)企業是否正在開發微服務并在基于云計算的微服務架構上進行標準化?Mark Heath建議容器或平臺即服務(PaaS)都是不錯的選擇，在容器中托管功能也是如此。Heath表示，無服務器功能可能更易于配置且支持成本更低，而容器可以簡化內部部署開發，并提供更多選項來保護端點。

(7)云計算顧問Sarbjeet Johal指出，無論是構建平臺、應用程序還是服務，受眾是企業內部的、外部的還是面向客戶的，了解應用程序的類型和最終用戶的類型有助于企業預測將來的需求。Johal說：“對于外部應用程序，企業想要記錄更多的訪問控制，數據量可能會意外增長，并且與內部應用程序相比，外部應用程序的使用壽命可能更長。如果服務或平臺是機器消耗品，那么可能需要進行計量。”

預測路線圖和未來需求應有助于推廣某些選擇，并排除其他選擇。而在縮小選擇范圍后，優秀實踐就是進行概念驗證。