2020年12月1日，當世界為以COVID-19大流行為主導的動蕩年末做準備時，AWS為云社區帶來了早期的禮物。 對AWS Lambda函數的容器支持。將Lambda函數打包和部署為容器映像的能力，因此使您可以利用容器提供的好處運行Lambda函數。

無服務器功能使行業可以立即啟動并運行業務代碼。新穎的計算服務提供了擺脫設置復雜基礎架構和配置的復雜性以及在生產中運行的可伸縮性和相關操作的能力。

但是，無服務器產品處于當前狀態，因此受到很大限制。例如，當嘗試使用您正在使用的無服務器產品不支持的編程語言時，或者在鍵入以導入庫時。AWS Lambda層 通過允許用戶將所需的庫和外部代碼庫作為“層”添加到您的AWS Lambda函數之上來解決此問題。同樣，Azure提供了“綁定擴展” ，該綁定擴展用作社區的開放源代碼模型來構建新的綁定類型，然后可以將其引入您的Azure函數中。

不幸的是，這些方法在如何利用它們方面有局限性。因此， 對AWS Lambda功能的新容器映像支持遵循了AWS的目標，即提供緩解措施和解決方案來緩解云社區所面臨的障礙。

結合并平衡無服務器和容器產品的功能，這不是一個新的跨越。問題在于，無服務器帶來的好處使計算范例極具吸引力，但同時也導致靈活性和使用性受到其他限制。這是有蛋糕卻不能吃的古老諺語。

但是，云供應商現在正努力克服這一問題，因為他們競相提供各種云計算服務，并通過提供方便的靈活性的功能來增強這些服務?？紤]考慮在列出這些折衷時可以進行的各種排列，每項服務都提供自己的折衷。這樣做的目的是提供足夠多的服務產品列表以及這些服務中的功能，以確保它們可以通過其多樣化的客戶群最好地滿足云市場的需求。

例如，AWS提供 EC2容器，AWS Lambda函數和AWS Fargate。Azure 和GCP 提供類似的服務，例如Azure容器注冊表，Azure容器實例，Google Cloud Run等。此外，我們可以注意到一些功能，例如AWS Lambda層，AZure Binding Extensions和各種其他增量改進。

可以看出，云供應商擁有跨計算范式和范式本身的高級服務。除了我們在這些供應商的無服務器產品中注意到的改進之外，我們還看到無服務器容器的興起，即容器即服務（CaaS）。因此，本文的目的是探索容器即服務的概念，并認可著名的云供應商AWS，Azure和Google Cloud在云中可用的當前服務。

探究CaaS范式

云計算的誘人前景之一是大大降低了管理服務器硬件的復雜性。隨著云產品的興起，我們可以簡單地將硬件管理職責委托給云供應商。但是，我們現在必須學習如何通過云供應商平臺配置虛擬服務器，從而引入一種新型的操作負擔。多年來，基礎架構即服務（IaaS）已從容器即服務（CaaS）演變為最終功能即服務（FaaS）。這些不同的范例都提供不同的抽象級別，而FaaS是最容易使用的范例，因為它具有最多的抽象級別。

自然，云開發人員會急于使用FaaS服務，此后已經成為無服務器 產品。但是，有一個陷阱。隨著更多的抽象導致更少的操作負擔，人們不得不犧牲靈活性并忍受操作限制。

例如，對于可以被視為IaaS范式的Amazon EC2實例，您必須指定規則，網絡安全監控等等。除了容器編排之外，主要問題還在于自動縮放，因為在容器級別定義縮放規則非常繁瑣。但是，所有這些額外的操作負擔確實意味著您幾乎可以按照任何希望的方式來配置環境。因此，您可以選擇任何運行時，例如，不必擔心超時限制，還可以定義最適合您的業務需求的精細自動縮放規則。

但是，有了這種增加的靈活性，您將失去無服務器的三個主要特征，這也是計算模型的最大優勢。這些如下：

· 服務器管理抽象給供應商

· 隨用隨付模式，您只需為使用的商品付費

· 自動可擴展且高度可用

這就是CaaS范式旨在通過方便地坐在容器和無服務器服務之間來達到最佳效果的地方。要了解如何操作，讓我們考慮該領域的三家主要云供應商提供的CaaS產品。

浮在云端的容器

AWS Fargate

與分別是傳統Iaas和FaaS服務的Amazon EC2和AWS Lambda函數相比，AWS Fargate是AWS的CaaS解決方案。因此，與Amazon EC2不同，已經建立了容器基礎架構，包括網絡，安全性，最重要的是擴展。使用該服務，您只需要為每個容器實例指定資源，然后讓Fargate在后臺進行工作即可。

每個Fargate實例都帶有其專用的ENI， 以允許任務間群集之間進行通信，而同一任務的群集則通過localhost進行通信。此外，這些任務的管理再次由ECS完成。Fargate被定義為ECS的計算引擎，提供了一種不同的任務管理方式，這就是Fargate將其鏈接到容器服務的定義特征。

但是，這只是Fargate的一面，也有整個無服務器的一面，這是由于它建立在AWS Firecracker之上。因此，能夠實現所需的自動擴展風扇有助于按需付費模型。

Azure容器實例

Azure 在2017年中宣布Azure容器實例（ACI）時，成為第一家提供CaaS服務的云供應商。其目的是為了簡化開發人員設置容器實例的經驗，從而在其CaaS產品中引起所有其他供應商的共鳴。

考慮到安全性，網絡和存儲，ACI允許設置具有預配置屬性的隔離容器。例如，所有ACI都增強了其安全能力，因為其各自的容器模型在虛擬機監控程序級別提供了保護。這使得ACI成為多租戶用例的理想解決方案。此外，計費模型遵循無服務器計算服務的計費模型，在該模型中，ACI的采用者只需按 每秒使用的內存和vCPU數來支付他們使用的資源，這與AWS Fargate相似。

必須注意，定價模型可能會因Azure提供的不同資源類型而異。但是，這也是因為AWS Fargate在不支持特殊容器（例如GPU）的情況下限制了您可以預配的容器類型，這些特殊容器在ACI中可用，但由于明顯的原因而定價不同。

Azure提供了一個高度集成的生態系統，可以在采用ACI時增強開發人員的體驗。例如， 在部署容器映像時，我們可以利用Azure容器注冊表（ACR），類似于Docker注冊表。此外，還有一些工具和服務，如Azure的門戶網站，Azure的CLI ， 和Azure的資源管理器 在我們的處置模板。

我們應該探索的第三個CaaS服務是Google Cloud的Cloud Run。這是這組CaaS列表中發布的最新服務，將于2019年11月開始普遍提供。使用Google Cloud Run，開發人員可以置備無狀態容器，類似于其他兩家供應商提供的CaaS服務。借助該服務，Google設法保留了無服務器的核心優勢，同時以對其他編程語言，系統二進制文件或任何所需的庫的支持的形式提供了額外的靈活性。

盡管Google Cloud Run是最后進入市場的產品，但Google已經以Google Kubernetes Engine（GKE）的形式提供了某種CaaS服務。作為Kubernetes的創造者，Google提供完全托管的Kubernetes服務是很自然的。丈量Atamel 談到GKE，以及如何在他帶來Kubernetes到無服務器平臺的談話 在ServerlessDays伊斯坦布爾。

我之所以將GKE描述為某種CaaS的原因是，根據我的說法，它更多地是Kubernetes即服務（KaaS）產品而不是CaaS。這是因為它不完全遵守即付即用模式。手動創建GKE集群時，節點和環境將永久可用，因此無論使用情況如何，都將產生成本?？紤]到這一點，Google Cloud Run更加無服務器，因此可以更好地定義為CaaS服務?？傮w而言，在比較GKE和Google Cloud Run時，我們看到后者需要按需付費的模型，因此編排較少，更貼切。

結論

隨著向云計算的發展，云供應商正在不斷創新以滿足客戶的需求。隨著行業開始采用云技術，容器編排成為發展的主要痛點。為了緩解這些問題，我們看到了無服務器時代的到來。即使新穎的計算模型設法抽象了所有基礎架構設置，但它還是犧牲了靈活性。因此，現在看到無服務器容器的興起，兩全其美。

AWS，Azure和最近的Google Cloud都已通過各自的服務進入該領域。無論他們提供的產品有何不同，我們都看到這三個目標之間的共鳴。在簡化容器編排的同時，仍保留所需的靈活性，以便利開發人員在使用云的過程中的眾多用例，從而總體上促進云的采用。畢竟，自從過去十年以來，云的概念一直是軟件的主要焦點，從而改變了軟件的構建和運行方式。CaaS只是通過創新方式改善了體驗，使偉大發明家Thomas Edison的創新路線永垂不朽。“一個想法的價值在于它的使用”。