越来越多的公司采用容器技术来部署云应用，容器与云平台貌似已经紧密结合起来了。所以，三大云平台供应商——亚马逊云计算平台、微软云开发平台和谷歌云平台，在市场中推出各自的容器服务也就不足为怪了。然而，这些容器服务各有利弊，到底怎么样？以下是技术评测。不过，最终还是取决于你的应用程序需求。

评测是来自波士顿的云咨询公司，通过针对容器技术对顾问们征询意见，并对用例进行调查，就亚马逊云计算平台、谷歌云平台及微软容器服务开展了一次内部商讨。

三大云厂商提供商的容器产品评分表

具体来说，评估或使用云容器服务过程中重要的几个方面，包括数据管理、可扩展性、性能、安全、DevOps、集成管理和运行(结果如表1所示)。用途涵盖开发和运营管理方面。简而言之，基本包括了在创建、使用基于这三种容器服务技术的应用程序时，所要涉及的所有方面。

打分为1-5分制：1分为最低分，5分为最高分。得到1分意味着该技术根本未对所涉及范畴提供支持，得到5分则意味着该技术符合所涉及范畴的大部分特点和功能要求。DevOps这一范畴的其中一个要求是，容器子系统可以支持DevOps运行，或者可以提供一个集成配置库。

当然了，本文只是针对谷歌、亚马逊或微软所提供的容器服务进行评估的公司提供一些根据。你自己的应用程序需求是最终决定你选择哪个容器的最终答案。

微软容器服务（ACS）基于一个开源容器编排系统Apache Mesos。这表示你可以先考虑早于ACS出现的Mesos的特点和功能，继而对ACS的特点和功能做一些良好的假设。目前尚未广泛应用的ACS是此前提到的三种容器服务中最新的。随着我们获得更多日新月异的微软容器的相关数据点，该容器服务会有很多变化。

在使用AWS EC2 Container Service (ECS)过程中，我们发现一些运行问题，比如说无法细粒度监控容器。ECS集成管理和运行本该像亚马逊其他服务一样强大，但与 Google Container Engine (GKE)'s的五分成绩相比，ECS只能打个4分。然而，ECS提供包括 CloudWatch集成在内可以助其与ACS竞争的服务。与此同时，ACS仅支持Linux容器，微软端口Mesos over, .NET developers，落后于主流产品。

在数据方面，这些容器服务都提供本土数据连接，不强迫使用外部应用程序接口，但仍有提升空间。值得关注的是，这些容器服务会将容器与本土数据服务结合，但不提供开放数据访问，因后者强调可移植性。如果数据与容器紧密连结，创建可移植容器会很困难。这是目前需要关注的一个新兴领域。

考虑到安全方面，我们发现，借助于Kubernetes容器编排系统，谷歌容器服务拥有“秘密”功能和一些其他的资源限制，而这些是其他两家容器服务所缺乏的。因此，在安全方面，GKE排名较高。但要注意，微软也在使用Kubernetes，只是方式不同。该技术本身大部分是按照用户需要选择的。

然而，考虑到主平台，或者容器服务所依托的公共云平台，非常有趣的是，一直宣称注重安全性的谷歌平台，在一些方面倒是不如AWS或者Azure。表现在，谷歌可以与第三方访问权限管理工具合作，却缺少本土访问权限管理工具支持。尽管这不影响图表中的排名情况，但是，这是你选择平台时需要考虑的事情。

谈到DevOps，GKE和Amazon ECS拥有各自的注册表，通过各自的云平台容器服务，Google和AWS可以提供更好的DevOps集成管理。而Azure Container Service没有。

可扩展性也与你的应用程序需求相关，所以我们基于这些应用程序的机制，比如Mesos，和一些项目案例做假设。在利用这些技术时，你可以通过相同的途径去控制和执行你的容器。比如说，Mesos的ACS可以提供不错的可扩展性，但仍不如GKE，因为后者可以提供更好的集群功能。

众所周知，亚马逊ECS可以提供高质量的可扩展性，这也是取决于AWS容器引擎所带来的高度可扩展的平台特征。

总的来说，Google offering更先进，这很大程度上得益于与其自身的Kubernetes容器集群和谷歌开发运营支持的紧密结合。然而，谷歌容器服务并未领先那么远得，以至于让AWS和微软容器服务无法短期内赶上。毕竟AWS的市场占有额还是最大的，它极有可能会在不远的将来提供更好的容器工具。 

备注：文章翻译自techtarget.com，Cloud Technology Partners公司主要架构师Mike Kavis, Sibu Kutty and Jonathan Baier促成本文。

翻译：津上