容器评估：Azure容器 VS. Google VS. AWS

越来越多的企业使用容器技术部署云应用，似乎容器和云的关系越来越紧密。因此三大云供应商--Amazon Web Services， Microsoft Azure和Google工——都推出了各自的容器服务。但是，这些服务并不完全一样。

为了达到本文的目的总部位于波士顿的云计算咨询公司，Cloud Technology Partners，深入分析了Amazon Web Services（AWS），Google和Azure容器服务，仔细考量了用例。该公司仔细考察了评估或使用基于云的容器服务时需要重点研究的特性，包括数据管理、扩展性、性能、安全、DevOps以及和管理运营的集成（结果见表1）。用例覆盖了开发和运维，简单来说，覆盖了当你使用这三种技术构建并且部署应用程序所必须使用的功能。

比较三大主流云供应商按需容器产品的评分。

1-5的分值，1是最低分，5是最高分。打分为1意味着该技术完全没有提供对该项的支持，而5意味着该技术满足了该项的绝大部分特性和功能需求。在DevOps项考察的需求，是容器子系统支持DevOps运维，或者提供集成仓库的能力。

对于正在评估Google、AWS或者Azure容器服务的企业来说，本文提供了一些基本知识。但是你自己应用程序的具体需求才是驱动最终产品决策最重要的因素。

集成和数据考量

Azure容器服务（ACS）基于Apache Mesos，一个开源容器编排系统。这意味着受益于ACS的前身， Mesos的特性和功能的良好口碑，用户可以认为ACS的特性和功能还不错。ACS，还没有完全可用，是之前提到的容器服务里最新的一个。随着Microsoft容器产品的进一步开发，我们会得到更多数据，很多得分可能会随之变化。

Google并没有领先太多，AWS和Microsoft可能会快速赶超。

AWS EC2容器服务（ECS）里，我们能够看到一些运维问题，比如不能细粒度监控容器。当考察ECS和管理以及运维的集成能力时，应该和其他AWS产品一样强大才对，和Google容器引擎（GKE）的5分对比，我们不得不只给4分。但是，ECS的确包括CloudWatch集成，这点和ACS相比是一个优势。另外，现在，ACS还仅仅支持Linux容器。Windows支持就快好了，Microsoft引入了Mesos，.NET开发人员暂时还不能使用这项服务。

从数据的角度看，所有这些服务都提供了原生数据链接，而无需强制使用外部API——但是还有改进的空间。一大顾虑是它们会将原生数据服务和容器绑定到一起，并且不提供开放数据访问，这样能够加强便携性。如果数据紧耦合到容器里，那么就很难创建便携的容器。这是一个新兴的领域，我们会持续关注。

AWS、Google和Azure容器安全性

当考虑到安全性时，我们发现Google的服务，通过其Kubernetes容器编排系统，拥有一个“秘密”功能以及一些其他两种服务没有的额外的资源限制。因此，GKE在安全性上得分最高。要记住Microsoft也使用Kubernetes，但是以不同的方式实现。该技术的大部分内容对于用户而言都被抽象了。

但是，当考察托管平台时，或者容器服务运行的公开云平台，很有意思的一点是Google平台，当涉及到安全性时，比AWS或者Azure稍稍落后一点。虽然Google能够和第三方认证访问管理（IAM）工具一起工作，但是它缺少对原生IAM的支持。虽然这一点没有影响上表里的评分，但是这也是决定使用哪种平台时需要考虑的方面。

DevOps和扩展性

当考虑到DevOps时，GKE和Amazon ECS都拥有自己的registry，但是Azure容器服务没有。当考虑到各自云上的容器服务时，Google和AWS提供了更好的DevOps集成。

扩展性要求和你的应用需求相关，因此我们得基于他们能够提供的机制做假设，比如Mesos，以及一些我们在项目中看到的用例。当考察这些技术用来托管并且运行容器时，你可以使用相同的方案。比如，使用Mesos的ACS，应该能提供还不错的扩展性，但是没有GKE那么好，GKE能提供更好的集群能力。

众所周知，Amazon ECS能提供高质量的扩展性，主要依赖于AWS带给其容器引擎的高可扩展平台特性。

综上所述，受益于Google产品和其自己的Kubernetes容器集群，以及Google的开发和运维支持的紧密集成，Google的产品总的来说更先进。但是Google并没有领先太多，AWS和Microsoft可能会快速赶超。基于AWS的市场占有额，它很可能近期就能提供更好的容器方案。

本文转自d1net（转载）