企業在為基於容器的應用程序選擇雲計算架構時需要了解關鍵問題和注意事項。
想象一下，走進一家專賣漢堡包的雜貨店，裡面有各種各樣的漢堡包，雖然有很多選擇，但只有漢堡包。
如果你是一名漢堡包廚師，可以在店裡選擇牛肉、雞肉和其他蛋白質，以及奶酪、麵包、蔬菜、調味品以及其他製作漢堡包的食材，甚至還可以選擇盛餐的盤子和容器。
如果你沒有時間、技能或興趣自己製作漢堡包，那麼可以在店中購買漢堡包。除了傳統的選擇之外，還有素食漢堡包等。只需按照工具包中的說明進行操作，就可以吃到一個美味的漢堡。
如果漢堡包廚師突然得到通知，需要在午餐前的兩個小時內製作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說：“對於外部應用程序，企業想要記錄更多的訪問控制，數據量可能會意外增長，並且與內部應用程序相比，外部應用程序的使用壽命可能更長。如果服務或平臺是機器消耗品，那麼可能需要進行計量。”
預測路線圖和未來需求應有助於推廣某些選擇，並排除其他選擇。而在縮小選擇範圍後，最佳實踐就是進行概念驗證。
閱讀更多 企業網D1Net 的文章
