• ハイパーバイザー：VMではハイパーバイザーの要件が大きな存在だ。必然的にハイパーバイザーのインストール先とそのバージョンに縛られることになる。VM変換ツールは豊富にあるが、変換プロセスは別のハイパーバイザーへ移行する前に実行しなければならない。一方、コンテナはハイパーバイザーに依存しない。ただし幾つかの依存関係はある。例えば、DockerコンテナにはDockerが必要であり、他のコンテナエンジンでは必ずしも動作するわけではない。
• バックエンドサポート：VMではアプリケーションのバックエンド向けにさまざまな機能が提供されている。Dockerコンテナをバックエンド向けに作成するのはあまり実用的ではない。「コンテナの有効期間は比較的短くあるべきだ」というコンテナの理念にも適さない。リリースのたびに運用中のコンテナを全て破棄して、新しいコンテナに置き換えるのが理想的だ。
• サイズ：バックエンドへのサポートが不足していると、コンテナが肥大化する恐れがある。だが、不足がないのであればコンテナの方が、はるかにサイズが小さくなる。フロントエンドアプリケーション開発に限って言えば、Dockerコンテナへの実装の方がVMで同様の作業をする場合よりもかなり小さいサイズになる。つまり、物理イメージファイルのコピーを必要とするプロビジョニングであれば、コンテナを使用する方がはるかに高速になる。
• 速度：ホストOSと比べた処理速度の遅さは重要な考慮事項になる。VMでは速度が低下する。一方、コンテナでは、Dockerが使う小さなオーバーヘッドを除けば低下は起きないといえる。コンテナの方がVMよりもパフォーマンス面のメリットは大きいが、これはよく争点になる。ほとんどのDockerインスタンスがVMで実行されるためだ。VMと比べた場合速度は低下しないかもしれないが、VM自体が稼働するベアメタルホストに対しては速度が低下する。コンテナはローカルマシンではなくVMで実行するのがベストプラクティスになるケースが一般的だ。
• ホストOS：VMは完全にホストOSから分離される。それに対して、Dockerはメモリとディスク領域を分離するが、同じホストOSカーネルを使用する。加えて、DockerではVMほど多くのホストOSあるいはコンテナOSのオプションを使えない。Microsoftユーザーの場合は、同社の「Windows Server 2016」でDockerを実行する選択肢もある。だが、VMの方がコンテナよりも選択肢が多いことに変わりはない。
• ネットワーク：VMには多様なネットワーク機能のセットがある。VMでは、ネットワーク化されたVM群を使った仮想ネットワークを構築できる。スナップショットの作成も可能だ。そのため、VMの方が、はるかに柔軟性が高い。ただし、これはデスクトップ環境には有用でも、アプリケーション開発にはそれほど関係ない。コンテナもネットワーク化は可能だが、テクノロジーはVMほど成熟しておらず、構成も複雑になる。
• イメージ：VMのスナップショットとコンテナのイメージは、どちらもインスタンスのライブラリを管理する方法だ。開発者はこれらのインスタンスをプロビジョニングできる。DockerにはないVMの機能の一つに、メモリの状態を一時停止して保持する機能がある。これによりフルスタックの導入を迅速に進めることができ、アプリケーションのバグ解消が可能となる。Dockerではコンテナ内の全てのプロセスを停止させる「pause」コマンドと、その停止を解除する「unpause」コマンドが使用できる。だが、依然としてこれはアクティブなインスタンスでしか使えない。
• 管理：VMとDockerコンテナは管理に関してそれぞれ独自の懸念事項を持つ。開発者はDockerコンテナをアプリケーションコンポーネントのように扱わなければならない。つまり、バージョン管理を実行し、リポジトリに保存する必要がある。Dockerコンテナはレイヤー構造で構築され、変更可能な部分が多い。そのため、全ての変更を追うことが重要になる。VMにも変更は加えられるが、さほど多くはない。一般的なハイパーバイザー構成に含まれるVMの数に比べて、一般的なDocker構成に含まれるコンテナの数の方が多くなりやすい。そのため、VMよりもコンテナの方が無秩序に広がっていく可能性が高い。
• 移植性：通常、DockerコンテナはVMよりも移植性に優れる。サイズやネットワークなどが要因だ。VMを移植するとしても、Dockerコンテナほどシームレスには実行できない。新たに作成したDockerコンテナのインスタンスは、オーバーヘッドなしで好きな場所にプロビジョニングできる。

性質面の比較

　テクノロジーの導入が人間に及ぼす影響を定量化するのは難しい。ただし、影響が全くないというわけではない。

　Dockerは、その開発者が開発者のために構築したツールとしてリリースされた。その結果、開発者は各自の開発フローにおけるDockerの役割を理解し、はるかに簡単にDockerへアクセスできるようになった。例えば、Dockerはリリース自動化やフルスタック導入のための適切な機能を備える。一方、VMは開発も含めて全てのインフラをIT部門が管理していた時代に導入された。

　加えて、VMはハイパーバイザーと結合しており、要求される容量も多い。そのようなハイパーバイザーを調達するプロセスも通常は必要になる。その結果、VMでは最新のDevOps（運用開発）デリバリーチェーンがコンテナを利用した場合ほどはうまく回らない。

　ただし、繰り返しになるが、比較的明白かつ大事な要素が1つあることを忘れてはならない。Dockerはほとんど常にVMで実行される。VMは「設定したら忘れてしまう」類いのインフラであるため、VMでDockerを実行することは柔軟性の向上につながる。

　開発にVMを導入する欠点は、結果としてほとんどの組織構造がVMを中心に構成されてしまうことだ。アジリティー（俊敏性）の点ではDockerに軍配が上がる。だが、サイズやマシン速度をはじめとする主な違いを除けば、最新のソフトウェアデリバリーチェーンにおいてVMを本格的なコンテナとして扱う選択肢も十分考えられる。