コンテナ同士は互いに高度に分離されている。同じホストで実行していても、あるコンテナで実行しているプロセスから、別のコンテナで実行しているプロセスを確認できない。影響を及ぼしたり、やりとりしたりすることも不可能だ。コンテナはネットワークのスタック（構成要素）を共有しないため、別のコンテナのネットワークソケット、ポート、インタフェースにはアクセスできない。

　小規模なサービス（マイクロサービス）を組み合わせた「マイクロサービスアーキテクチャ」を利用して構築したモジュラー式アプリケーションの場合、問題が複雑化する｡このようなアプリケーションは通常、サービス群を中心に構造化されている。これらのサービスは別々のコンテナの個別プロセスとして動作し、REST API（システム連携の設計原則「REST」にのっとったAPI）経由で通信をする。

　各コンテナはデフォルトで固有の動的IPアドレスを持っている。ネットワークを使用するワークロード（システム）のために、コンテナホスト側でネットワーク接続を自動で確立することはない。Dockerランタイムはデフォルトで仮想ブリッジ（異なるネットワーク同士を接続する機器）を用意しており、接続する全てのネットワークへパケットを転送する。この仕組みにより、ホストを共有するコンテナ同士が接続でき、簡単に通信できる。

　ブリッジは融通の利かない通信経路だ。ただし開発者は、ネットワークを定義することでアクセスを制御し、特定のコンテナのみが特定のポート経由で通信できるようにすることができる。ユーザーが定義したネットワークにも永続的なIPアドレスを用意し、Dockerの組み込みDNS（ドメインネームシステム）サーバへアクセスして名前解決できる。これによりコンテナ間の通信が容易になる。Dockerクラスタ管理ツール「Kubernetes」で構成したクラスタのように、内部システムでコンテナをホストする場合、コンテナ間通信にデフォルトのブリッジを使用できる。

　AWS、Microsoftの「Microsoft Azure」、Googleの「Google Cloud Platform」など、パブリッククラウドサービスを対象にコンテナを使用する運用担当者に、1つアドバイスがある。各クラウドサービスが提供する具体的な機能を調査してほしい。例えば多くの場合、コンテナの運用ワークロードでサポートしているネットワークに関して、ドキュメントは明確さを欠いている。例えばAmazon ECSは、ユーザー定義のネットワークについてはサポートの有無について言及しておらず、そのサポートはないと推測できる。

　クラウドサービスは、各サービス固有のID／アクセス管理サービスを利用してコンテナを管理する方法を用意している。そのため複数のコンテナベースのマイクロサービスに基づくアプリケーションを導入するには、その前に適性評価を実施する必要がある。

　コンテナは、さまざまなインフラでのアプリケーション導入を単純化し、合理化する。ただしユーザー企業がコンテナの制約を理解した上で対処し、幾つかの簡単なルールに従えば、という条件が付く。

　Linux開発者は最新のディストリビューションを使用して、コンテナイメージを構築する必要がある。Windows開発者の場合は、Windows Server 2016またはWindows 10を採用し、Windowsコンテナをホストすることになる。Windowsコンテナのホストには、Microsoft Azureのような互換性のあるコンテナサービスも利用できる。LinuxホストでVMを実行することは可能だ。だがパフォーマンスに影響するオーバーヘッドが生じるため、お勧めしない。