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的创新路线永垂不朽。“一个想法的价值在于它的使用”。
