随着云计算技术的迅速发展，容器技术因其轻量级、可移植性强、易于管理等优势，逐渐成为企业部署应用的首选方式。然而，当企业将应用部署到生产环境中时，他们希望构建一个既可靠又高效的基础设施，并且能够轻松管理。这时，许多组织开始寻找容器管理工具，或者称为容器即服务（Container-as-a-Service, CaaS）的解决方案。
容器即服务（CaaS）的概念自2014年诞生以来，与虚拟机（VM）相比，Docker等容器技术仍然相对较新。容器需要一套全新的工具集。与用于管理监控、安全和配置管理的集成工具不同，Docker工具链更加分散。它由许多单一用途的工具组成，这些工具集成在一起提供整体服务。这些工具大多是开源的，旨在在生态系统中工作，而不是独立工作。最初，自行运行和管理Docker相对容易，但很快，随着需要集成和更新的组件数量的增加，管理的复杂性也会随之增加。当从相对静态的VM世界过渡到容器的动态设置时，不希望牺牲易用性。这时，CaaS平台的优势就显现出来了。它通过让从单一的控制面板管理容器，为提供了更多的控制权。由于CaaS解决方案由供应商完全管理，可以放心使用，无需担心维护问题。使用CaaS解决方案的最大优势在于，它让专注于构建应用和添加新功能，同时消除了常常阻碍软件开发的基础设施问题。
在开始选择适合CaaS解决方案时，可能会面临众多选择，这可能会让感到不知所措。但是，当研究每个解决方案的架构以及它们管理容器的方法时，每个解决方案的优势和劣势就会变得清晰。让看看一些最受欢迎的CaaS产品，并与阿里巴巴云容器服务进行比较。
AWS ECS是一个流行的CaaS解决方案。根据最近的一项调查，它在生产环境中运行容器的公司中占有约32%的市场份额。调查还指出，大多数ECS用户正在尝试多种解决方案。目前，46%的ECS用户也在使用Kubernetes，35%的用户在使用Swarm。这些数字表明，容器解决方案的演变还处于早期阶段，用户对尝试多种解决方案持开放态度。
ECS在EC2实例上运行Docker容器，并在每个活动的容器实例中安装ECS代理。ECS代理负责在容器实例中执行任务。它使用AWS ECR作为默认的容器注册表，但也可以使用Docker Hub作为注册表。
选择ECS作为CaaS解决方案的最大原因是，如果大部分基础设施都在AWS上运行，并且只是想尝试容器。然而，一旦开始运行生产工作负载，ECS可能会变得有些古怪。
ECS的最大缺点是它不提供对Kubernetes的原生支持。相反，ECS利用第三方发行版，如Kops或CoreOS Tectonic。虽然这可以工作，但它通过增加更多的复杂性到堆栈中，牺牲了开发人员的生产力。随着AWS最近加入CNCF，这种情况可能会很快改变，但就目前而言，这对ECS及其用户来说是一个困境。
Azure与ECS有一些共同点，比如在Azure虚拟机上运行容器，并且不收取AKS服务费用，只收取Azure资源如计算和存储的费用。然而，AKS在与Kubernetes的集成方面领先于ECS。Azure使用开源的上游Kubernetes发行版，并简化了主节点和代理节点的管理和维护。它提供了自动升级，并且很容易开始使用，只需要三个命令就可以启动一个新的Kubernetes集群。这些特性是Azure的新功能，因为它刚开始专注于提供Kubernetes作为服务。
阿里巴巴云容器服务将CaaS的最佳特性整合成一个引人注目的解决方案。阿里巴巴容器服务与前两者类似，它也在其弹性计算服务实例上运行容器，并且只收取使用的资源费用，不收取容器服务本身费用。
阿里巴巴云容器服务支持Swarm和Kubernetes，并且与Kubernetes的集成非常好。它支持上游Kubernetes发行版，并且作为云原生计算基金会（Cloud-native Computing Foundation, CNCF）的成员，阿里巴巴密切参与了Kubernetes的发展。