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服務。總體而言，在比較GKE和Google Cloud Run時，我們看到後者需要按需付費的模型，因此編排較少，更貼切。
結論
隨著向雲計算的發展，雲供應商正在不斷創新以滿足客戶的需求。隨著行業開始採用雲技術，容器編排成為發展的主要痛點。為了緩解這些問題，我們看到了無伺服器時代的到來。即使新穎的計算模型設法抽象了所有基礎架構設置，但它還是犧牲了靈活性。因此，現在看到無伺服器容器的興起，兩全其美。
AWS，Azure和最近的Google Cloud都已通過各自的服務進入該領域。無論他們提供的產品有何不同，我們都看到這三個目標之間的共鳴。在簡化容器編排的同時，仍保留所需的靈活性，以便利開發人員在使用雲的過程中的眾多用例，從而總體上促進雲的採用。畢竟，自從過去十年以來，雲的概念一直是軟體的主要焦點，從而改變了軟體的構建和運行方式。CaaS只是通過創新方式改善了體驗，使偉大發明家Thomas Edison的創新路線永垂不朽。「一個想法的價值在於它的使用」。