容器和Serverless要怎么结合，AWS/Azure/GCP都给出了方案

要Serverless应用还是要容器化应用？

大家在用AWS Lambda的时候，通常只需要上传代码就行，无需关注服务器配置，但是当用户还想用容器技术的时候，就发现它跟Lambda还是很不一样。

AWS上个月介绍了一项关于Lambda的更新，允许用户将Lambda函数打包成容器镜像，最大镜像能达到10GB。此次更新意味着用户可以创建和部署有许多依赖包的大型工作负载，比如机器学习这类负载。

与把函数打包成ZIP包一样，把函数打包成容器镜像同样能享受到Lambda一样的体验，包括简便的操作性、自动伸缩性、高可用性等优势。

Serverles能使用户在瞬间运行业务代码，它摆脱了设置复杂基础设施的麻烦，并且能轻松在生产环境中提供可伸缩性能力。

但是Serverless也有其局限性，比如，有些编程语言是不支持的，有些库是不支持的。AWS Lambda通过允许用户自己添加库和外部代码，这一特性叫做“Lambda layers”。

类似地，Azure提供了绑定扩展（Binding Extensions）特性，用于构建新类型的绑定，这些绑定可以引入到Azure Functions里。

把Serverless和容器的能力进行结合的做法并不新鲜，Serverless优势虽然非常明显，它提供的计算范式非常有吸引力，但正因为如此，随着用户增多，其灵活性和使用限制方面的问题也越来越突出。

云厂商为了解决用户既想要Serverless，也想用容器化的需求，推出了一系列方案：

比如，AWS有EC2容器实例，AWS Lambda，AWS Fargate，EKS，ECS，ECR，还有刚发布的AWS Lambda layers等。

Azure和谷歌云GCP也提供了类似的服务，比如Azure Container Registry（ACR），Azure Container Instance（ACI），Azure Bingding Extesions特性，谷歌云GCP的GKE和Google Cloud Run等等。

云计算厂商提供多种计算服务，除了Serverless上的改良方案，云厂商也在推行CaaS容器即服务方案，我们看看几家云巨头提供的CaaS服务。

介于IaaS和FaaS之间的计算范式：CaaS

云计算的优势在于极大降低了管理硬件的繁重工作，随着云计算的发展，用户需要操作的部分越来越少，更多工作将由云服务商来完成，IaaS是基础阶段，CaaS是高级阶段，而FaaS所代表的功能（函数）即服务则是终极阶段。

从发展演化的路线来看，FaaS的追随者将越来越多，不过，随着云厂商管理的抽象层的增多，用户虽然承担的管理负担越来越少，但是会牺牲灵活性，会受到越来越多的操作限制。

例如，AWS的EC 2实例是典型的IaaS，用户可以选择各种配置，配置网络防火墙规则和监视内容等，看起来挺麻烦。

又比如，在容器编排方面，最主要的问题还在于自动伸缩，在容器级别定义伸缩规则其实非常困难，这部分如果用户来操作其实也非常麻烦。

虽然麻烦，但能换来极大的灵活性。

这些操作意味着可以以任何方式进行配置，可以选择任何你喜欢的运行环境，还可以自己定义最适合业务需要自动伸缩规则。

增加灵活性就意味着丧失了Serverless的三大优势：服务器基础设施完全由厂商来管理；按用量付费；还有可自动扩展且高可用。

CaaS要解决这一问题，它是处于容器和FaaS之间的服务。我们认识一下三大云厂商的CaaS。

Azure Container Instances（ACI）

2017年中，当发布Azure Container Instances（简称ACI）之后，Azure成为第一家提供CaaS的云厂商。该产品旨在简化开发人员设置容器实例的操作，该产品推出之后，许多厂商开始跟进。

ACI可以设置预配置的容器，这些容器在安全性、网络和存储等方面都有优化。例如，所有ACI都增强了安全功能，在hypervisor级别提供保护，这同时也使得ACI有了很好的多租户能力。

ACI的计费模式属于Serverless的模式，按秒计费计算用户实际使用的资源，类似于AWS Fargate。

为了提高ACI的使用体验，ACI与许多Azure服务进行了集成。例如，在部署容器镜像时利用Azure容器镜像库（ACR），类似于Docker Hub。还可以使用诸如Azure Portal、Azure CLI和Azure资源管理器模板之类的工具和服务。

Google Cloud Run

谷歌云的Google Cloud Run是2019年11月正式提供发布的CaaS，是三大云厂商中发布最晚的一个。

Google Cloud Run可为开发者提供无状态容器部署服务，与另外两家的CaaS服务没什么大的区别。不过，Google Cloud Run不仅保留了Serverless的核心优势，同时还提供了额外的灵活性，支持额外的编程语言、系统二进制文件或各种关键的依赖库。

虽然Google Cloud Run是来的最晚的，但Google此前已经用GKE提供了某种程度上类似于CaaS的服务。作为Kubernetes的创造者，Google自然会提供全托管的Kubernetes服务。

其实我认为将Kubernetes作为一种服务的话，可以叫做KaaS，严格来说，其实GKE不算CaaS，主要的区别在于，CaaS的特点是要具备按用量付费的模式，而GKE这种服务，只要创建集群就一定会产生费用的，不管你用不用。

由于Google Cloud Run具备Serverless的特点，所以，叫做CaaS更合适。

AWS Fargate

AWS Fargate是AWS的CaaS方案，EC2是传统IaaS服务，AWS Lambda则是典型的FaaS服务。AWS Fargate已经构建好了容器基础设施，解决了包括网络方面、安全性方面，还有扩展性等方面的问题，使用的时候，只需为每个容器实例指定资源即可，其它操作交给Fargate。

每个Fargate实例都有专用的ENI（弹性网络接口），它负责进行不同任务集群之间的通信，而相同任务集群间的通信则由本地来完成。

此外，这些任务的管理是由ECS负责的，Fargate算作是ECS的计算引擎，同样作为计算引擎的还有EC2，Fargate提供了一种新的任务管理方式。

同时，Faegate也具备Serverless的特征，能够实现自动伸缩，能实现按用量付费的模式。

结语

云技术在不断发展，云厂商不断推出创新服务，随着云技术的广泛采用，容器编排将成为进一步发展的一大痛点。Serverless的出现对于基础设施的抽象更为深入，但它是以灵活性为代价的。Serverless与容器结合将实现更好的平衡。

AWS、Azure和GCP都进入了这一领域，虽然产品各有特征，但要解决的问题是一样的，都是要在简化容器编排的同时，保持灵活性，帮助开发人员在云端开发各个场景的应用。

过去十年以来，软件开发都非常聚焦在云计算领域，云计算重塑了软件的构建和运行方式。而CaaS的出现，则是在进一步提升云上构建和运行应用的体验。