DockerのコマンドラインツールがWindows上でそのまま動作すれば、DevOpsチームはローカル環境のWindows Server上にあるDocker Engineを管理できるだけでなく、遠隔地のLinuxホスト上にあるDocker Engineさえも管理できるようになる。また、Dockerのコマンドラインインターフェース（CLI）と「PowerShell」のコマンドレットによってコンテナの自動化が実現できる。管理者はいずれかを選択して自動化スクリプトに統合できる。
Microsoftは、Node.jsやPython、Rubyのプログラマーを含む、.NET以外の開発者に興味を持ってもらい、同社の統合開発環境（IDE）「Visual Studio」を使用してもらうために最大限の努力を傾けている。Visual Studioは「Visual Studio 2015 Tools for Docker」を用いることで、稼働中のDockerコンテナに対して直接コードを発行できるようになる。また、コンテナ内に配備したコードにブレークポイントを設定し、1ステップずつ実行できるようにもなる。このような統合により、コンテナ開発者は高い生産性を上げられるようになる。
Windowsにおけるコンテナのサポートは、ツールと互換性関連に焦点が当てられており、クロスプラットフォームアプリが開発できるわけではないという点は理解しておく必要がある。つまり、Windows Server上でLinuxコンテナを稼働させたり、Linux上でWindowsコンテナを稼働させることはできない。しかし、いずれのプラットフォームにおいても、そこで動作しているツールを用いて双方のコンテナを管理できる。
Windows Server ContainerとHyper-V Container
Microsoftのコンテナ哲学はWindowsに軸足を置いたものとなっている。同社はWindows Server 2016において、「Windows Server Container」と呼ばれる軽量コンテナと、「Hyper-V Container」（Technical Preview 3では未対応）と呼ばれる仮想化をベースにしたコンテナという2種類のソリューションを提供する。これらはいずれも、DockerのAPIを通じてアクセスでき、DockerのCLIやツールを用いて管理できる。
Windows Server Container：このコンテナではベースとなるOSカーネルが共有される。このようなアーキテクチャの採用により、高速な起動と効率の高いパッケージ化が可能になるとともに、ホスト単位でより多くのコンテナが動作可能になる。一方、コンテナが互いの隔離レベルを下げて、ローカルデータとAPIを共有するというアーキテクチャにより、コンテナを実行する方法がそれぞれから切り離されるため、セキュリティはさほど高くない。
Russinovich氏によると、これらのコンテナは強固な隔離や厳しいセキュリティ制限を必要としない均質なアプリに向いているという。このため、多数のコンテナで構成された大規模なマイクロサービスアプリは、Windows Server Containerを使用することで高いパフォーマンスと効率を実現できる。
Hyper-V Container：このコンテナにより、仮想マシンとコンテナの持つそれぞれの長所を享受できるようになる。各コンテナにはWindowsカーネルのコピーとメモリがそれぞれ割り当てられるため、Hyper-V ContainerはWindows Server Containerよりも高い隔離性とセキュリティレベルを実現できる。また、ホストOSやその他のコンテナとのやり取りが最小限に抑えられるため、より強固なセキュリティレベルを達成できる。ただ、リソースの共有に制約が課されるため、起動時間が増加するとともに、パッケージ化されたコンテナのサイズが肥大化する。
Hyper-V Containerの用途として適しているのは、パブリッククラウドのようなマルチテナント環境だ。このアプローチは、VMwareの「Project Bonneville」とよく似ている（なおProject Bonnevilleでは、「VMware vSphere」へのアクセスにコンテナAPIを用いるようになっている）。
ここで重要なのは、Windows Server ContainerとHyper-V Containerのいずれの実装もDockerと互換性を有している点だ。
