無服務器和容器化是近年來 DevOps 最流行的兩個流行語，這是有充分理由的。在正確的用例中，兩者都可以提高性能并降低成本。然而，盡管它們很受歡迎，但并不是每個人都了解無服務器計算與容器的區別。
在這里，為了幫助您開始使用這兩種技術，我們將了解每種技術的含義，比較它們，解釋它們如何相互補充，并探討無服務器與容器安全性的關鍵主題。
什么是容器？
容器是輕量級不可變軟件單元，包括運行應用程序的所有依賴項和代碼。容器運行在“容器運行時”（有時稱為容器引擎）之上，可以在廣泛的操作系統和平臺上運行。因為容器運行時提供了容器所需的所有系統資源，所以在傳統操作系統上部署應用程序的操作復雜性被最小化了。
容器還具有高度便攜性。容器運行時存在的任何地方，團隊都可以部署容器映像。此外，由于容器僅包含運行應用程序所需的內容，因此與虛擬機等替代方案相比，容器更輕便、速度更快。
容器平臺最流行的例子是 Docker。然而，Docker 并不是唯一的容器平臺。例如，Linux Container (LXC) 早于 Docker，并且今天仍在使用。此外，還有許多工具可以補充容器，例如用于大規模編排和管理容器部署的Kubernetes (K8s)。
什么是無服務器？
無服務器是一種計算模型，無需配置或管理基礎設施即可按需運行代碼。盡管顧名思義，無服務器計算涉及服務器。然而，企業根本不必擔心服務器基礎設施。相反，開發團隊只需將他們的代碼部署在無服務器平臺上，并且僅在該代碼運行并消耗服務器資源時才收費。
由于企業只需為他們使用服務器資源（例如 CPU）的時間付費，因此無服務器可能是一種很好的方式，可以最大限度地降低部署使用量大幅上升和下降的應用程序的成本。這是運行裸機服務器、虛擬機或容器的根本轉變。任何空閑時間都沒有成本，只有當應用程序正在積極運行和使用資源時才會收費。
此外，操作復雜性會降低，因為所有基礎設施都被無服務器平臺提供商抽象化了。DevOps 團隊只關注他們的代碼。無服務器計算平臺的熱門示例包括 AWS Lambda、Azure App Service 和 Google 的 Cloud Run。
常見用例
現在我們了解了什么是無服務器計算和容器，讓我們來看看它們最流行的一些用例。
流行的容器用例包括：
- 微服務。容器是微服務架構的構建塊。由于容器便攜、輕便且易于部署，因此它們非常適合創建松散耦合的微服務。
- 持續集成/持續交付。容器為 DevOps 團隊提供了一種消除開發、QA、暫存和生產部署之間環境差異的方法。因此，它們在持續集成/持續部署 ( CI/CD ) 工作流中非常有用。
- “隨處部署”。大多數現代企業都在混合云和多云環境中運營。無論企業需要在本地還是跨多個云運行應用程序，容器都可以勝任。
- 遺留應用程序遷移。在許多情況下，遺留的單一應用程序需要遷移到云端。將它們容器化使這個過程更容易。
一些最流行的無服務器用例是：
- 應用程序接口。REST API 和 GraphQL 實現等應用程序編程接口 (API) 是一種廣泛的無服務器計算用例。因為 API 事務是短暫的并且可以快速擴展和縮減，無服務器提供了一個可靠的平臺來構建 API 后端。
- 數據處理。無服務器可以使用簡單的功能從多個來源進行數據處理。因此，無服務器計算非常適合需要大規模處理和分析數據但又希望避免基礎設施管理的團隊。
- 物聯網。無服務器計算為物聯網設備和外部系統異步通信提供了一種事件驅動和直接的方式。
- 動態網站內容。Serverless 的教科書式功能之一就是為靜態網站添加動態內容和邏輯。例如，AWS Lambda 通常用于向托管在 S3 上的靜態站點添加動態功能。
當然，這些只是容器和無服務器計算可能實現的示例。一般來說，容器在任何需要可靠部署可移植、輕量級和不可變圖像的地方都很有用。無服務器計算在各種應用程序中很有用，在這些應用程序中，工作負載變化很大，并且優先考慮最小化基礎設施管理工作。
無服務器計算與容器：差異以及它們如何相互補充
正如我們所見，無服務器計算和容器有一些高級相似之處。它們消除了復雜性，使團隊更容易部署和擴展應用程序。但是，有幾個重要的區別需要考慮，包括：
- 成本結構。有了容器——無論是在企業上還是在云中運行——只要它們在運行，企業就會為它們付費。通過無服務器計算，企業只需為他們使用的東西付費。對于具有一致需求的工作負載，這可能沒有太大區別。對于高度可突發的工作負載，這可以通過無服務器顯著節省成本。
- 可測試性。借助容器，團隊可以在任何地方輕松測試您的應用程序。對于無服務器，團隊僅限于運行功能的云平臺，無法針對無服務器功能執行相同級別的測試。
- 部署。要向上或向下擴展基于容器的應用程序，必須以某種方式部署或縮減容器（例如使用 Kubernetes）。借助無服務器，ylcode 僅在供應商提供的“黑盒”平臺上執行。
- 操作復雜性。無服務器的“黑匣子”范式對于希望最小化操作復雜性的團隊來說是一個很大的好處。實際上沒有可使用無服務器管理的基礎設施。使用容器，可以將基礎架構管理卸載給提供商，但情況并非總是如此。
- 供應商鎖定。容器可以“隨處運行”，但對于無服務器，企業高度依賴于運行代碼的平臺。例如，使用 AWS Lambda 函數會使應用程序更加依賴 AWS 平臺，而使用 Docker 容器可以部署在任何可以運行 Docker 的平臺上。
盡管存在差異，但容器和無服務器計算并不一定相互排斥。例如，可以使用Docker 來容器化無服務器函數。此外，像谷歌的 Cloud Run 這樣的平臺旨在使用按使用付費的無服務器模型來部署容器。
了解無服務器與容器安全
與技術本身一樣，無服務器與容器安全性是一個微妙的DevSecOps主題。無服務器確實消除了許多與基礎設施管理相關的安全問題，但仍然涉及許多重要的無服務器安全考慮因素。例如，不安全的無服務器權限配置可能會在應用程序中造成漏洞。此外，支持無服務器工作流的更多功能和協議意味著需要保護更多潛在的攻擊媒介。復雜性的卸載也伴隨著安全權衡：因為服務提供商處理如此多的基礎設施，所以對無服務器部署的可見性是有限的。
另一方面，容器安全性也有其獨特的挑戰。例如，僅安全地采購和部署受信任的容器——并為它們打補丁——可能是一項運營挑戰。此外，身份和訪問管理 (IAM) 和容器配置管理是強大安全態勢的重要方面。
