Azure容器服务并没有在编排的辩论中选择站队，也并没有添加对Kubernetes的支持，或者比公有云对手提供更多的不同功能。
在新兴的容器编排大战中，微软已经将自己定位为云提供商中的瑞士。
微软对其初步的Azure容器服务进行了多次升级，例如与Kubernetes和基于Apache Mesos的DC/OS进行更深入的集成，以及在Azure上托管容器图像的新的私有存储库。根据开放性主题，Microsoft已经发布了Azure容器服务引擎的源代码。
Microsoft是Kubernetes的早期支持者，并支持它在Azure上的使用，但是使用Kubernetes 1.4，支持更深入，具有本机功能，因此用户可以创建Kubernetes集群以与其他Azure服务集成。
与此同时，DC/OS升级了，在其用户界面上添加了更多虚拟网络选项，以及作业调度和基于Marathon的编排。新的Mesos和Kubernetes功能目前正在公开预览。微软没有说它将什么时候全部支持这些容器。
微软不站队
微软在这个领域采取了与其最大竞争对手不同的做法——对最突出的编排工具提供了深入支持。毫不奇怪，Google Container Engine非常依赖Kubernetes——它是Google内部调度技术的开源版本，而Docker正在Docker Swarm上构建其平台，Mesosphere也依赖于Mesos。
一些突出的平台即服务产品（例如Red Hat OpenShift）也依赖于Kubernetes，而亚马逊则首次使用其EC2容器服务进行市场营销，并且已经建立了自己的专有工具来管理Docker容器。
Gartner的研究副总裁Richard Watson说，每种技术都确信它的编排技术将取得成功。微软已经提供了Swarm和Mesos的客户选择，所以它只有把Kubernetes添加到列表中，并修改主题，不强迫用户选择，才有意义，他补充说。
Watson说：“微软很明智地成为了容器编排市场中的瑞士，因为这一市场没有明确的赢家和输家。客户正在尝试许多不同的事情，在用于某些用例中，有些编排工具将会比其更好。”
当然，对于容器编排而言，成为中立平台是说比做容易。随着其服务的进步，在围绕着如何深入地与各种工具集成，以及何时解决本地问题，微软必须做出选择，
这也可能表明微软想成为Kubernetes生态系统的重要贡献者，Watson说。用户应该期望Kubernetes在Windows上正常工作，并在未来集群功能中引入Windows，这对混合环境IT市场很重要，他说。
微软利用Azure容器服务引擎在Azure服务上创建部署，并在GitHub上开源了基础代码。相比于定制化部署，目前还不确定微软这一做法如何让使用户在短期内直接受益，但它的目标是在Azure上，最终在Azure Stack上，开发和分享最佳实践。
在Docker发展初期微软Azure支持Linux容器，并与Docker合作在它的技术之上构建Windows版本，且本地支持在最新的Windows Server。451 Research的首席分析师Jay Lyman表示，由于微软在开源和DevOps的游戏中迟到了，因此它要加大力度在容器市场。
Kubernetes很受开发人员欢迎，但对企业IT来说，它仍然是新的，Lyman说。微软的这一举动可能反映了一种转变，因为公司不仅使用容器用于开发/测试和Web应用，而且还用于传统企业中的数据丰富的生产工作负载上。
Lyman说：“这种管理和编排工作变得越来越重要，容器应用向生产环境的转移，意味着人们希望供应商支持SLA且确保技术支持。
公有云容器服务在兴起
Watson听到的大量客户的心声，他们已经准备好将容器迁移到操作环境中，但是他们需要一个编排工具。由于这些工具可能难以管理，他希望看到大量公有云提供商提供这类服务。
“人们会意识到，允许提供商运行这些东西，事情会变得更好，如果他们已经在这些提供商的云上构建和运行了应用的话，那么与这些新的容器化应用集成将会更加容易”，Watson说。
新的Azure Container Registry表与Docker Registry v2兼容，它提供了一个私有存储库来存储Docker格式的镜像。该工具在11月14日的预览版本中提供，作为Visual Studio中的新的持续集成和开发功能，供多容器Linux应用使用。
