サーバ仮想化では、独立した物理サーバとしてVMを機能させるホスティング環境の構築が、基本的には第一の目標となる。VMについて物理サーバと同程度の安全性を確保し、アプリケーション同士がそれぞれのパフォーマンスに影響しないようにするためだ。最新のVM技術でもその目標は完全には達成されていないものの、実現にはかなり近づいている。

　サーバは柔軟なプラットフォームだ。ほぼ全てのネットワーク接続構成で、ほぼ全てのワークロードをホストできる。VMにもこの特性が備わっており、これがVMとコンテナを比較した際、ホスティングの観点においてVMよりも優れている点となる。多くのユーザーにとって、サーバの資本コストよりもVMの運用コストの方がより大きな懸念になる。VMでホストするアプリケーションとして運用することは、コスト面でも、従業員に要求される技術レベル面でも課題となる。

　コンテナはVMとして動かすように設計されていないし、サーバになるようにも設計されていない。コンテナはVMに比べてメモリ使用の効率が良く、より簡単に導入および管理できる。システム開発事業などを手掛けるCIMIが実施したユーザー調査では、VMとコンテナを比較してコンテナの方を導入した、あるいは検討していると答えた企業の多くは、その理由に導入や管理のシンプルさを挙げている。これらの企業は、サーバ単位でのワークロードの偏りを改善することを理由に掲げた企業よりも多かった。コンテナと比べて、VMの方が柔軟性と安全性に優れている反面、複雑さも上回っている。

　DockerとKubernetesの両方におけるコンテナの進化により、新たなエコシステムや分散プラットフォームが生み出されている。こうした新しい技術は、OSと連携したシンプルなコンテナを有するだけではない。そのようなコンテナを分散モデルにて実装し、分散ネットワークを実現するための推定モデルも有する。この導入モデルはVMやサーバ向けのモデルよりも制限が厳しいものの、ユーザーは運用上のメリットを評価している。アプリケーションを全て同じ方法で構築し導入できるなら、管理はより簡単になる。

コンテナとクラウドの関係

　コンテナの優勢を決定づける上で立ちはだかるのがクラウドだ。コンテナを用いたホスティングはVMほど安全ではない。加えて、ユーザーが他のユーザーに対して脅威をもたらしてしまうような行為に関しても、VMほどには分離されない。クラウドでホストされるコンテナは、標準的なIaaS（Infrastructure as a Service） VMのレイヤーで動作するためだ。つまりVMが動いていても、クラウドサービスの一部として埋もれてしまい、ユーザーには見えなくなる。将来的に、目には見えないVMがあふれ返る状況になると容易に想像がつく。

　VMが見えなくなる原因はクラウドだけではない。Docker、Kubernetes、Apache Software Foundationの「Apache Mesos」、Mesosphereの「Mesosphere DC／OS」や「Marathon」といった、さまざまなコンテナ技術のエコシステム同士が集まり、オーケストレーション層を作り上げている。この層は抽象的なリソースプールで実行される。「Amazon Web Services」（AWS）や「Microsoft Azure」などのパブリッククラウドを提供する各ベンダーは、このオーケストレーション層を自社のコンテナホスティングサービスに利用している。そのため、各エコシステムに基づき、ネットワーク機能やアプリケーション構造によって構築されたコンテナシステムの移植性は非常に高い。ライフサイクルを管理できるという点もメリットだ。ユーザーやアプリケーションはこの層を介してやりとりするが、中身は重要でない。VMが見えなくなった世界は、VMが全くない世界とは違うのだろうか。

VMの将来

　VMとコンテナの争いの結果、VMが敗北し姿を消してしまうことも十分あり得る。オーケストレーション層はアダプターとして機能する。つまり、下地にある各種ホスティングコンポーネントは、上位層にいるユーザーからは同じように見える。そうしたオーケストレーション層に直接組み込まれる下位層のホスティング機能が実装される可能性がある。VMは汎用（はんよう）サーバのようなホスティングプラットフォームとは別の方面に進化し、よりコンテナに似てくると予想される。サーバではなく、抽象化した理想的なコンテナホストのエミュレーションをVMで実行するようになるかもしれない。それがVMと呼ばれるにせよ、別の名前で呼ばれるにせよ、現時点で使われているものと似た形にはならないだろう。

　ワークロードホスティングの進化における2つ目の可能性は、最適化コンテナのホストと最適化関数（ラムダ）のホストが集約されることだ。各クラウドベンダーは、独自の最適化関数サービスを提供するために、オーケストレーション層と同じ概念を導入している。この構造では、実際にホスティングを担当しているプラットフォームがクラウドユーザーに隠される。その結果、クラウドベンダーはユーザーの邪魔をせずに、基盤となるプラットフォームを強化できる。関数ホスティングとコンテナホスティングには似た要件が多い。そのため、クラウドベンダーがこれらの機能やオーケストレーション層を組み合わせ、1つのシームレスなプラットフォームを作り上げる可能性がある。

　コンテナエコシステムのネイティブな拡張は、Kubernetesを基に進化している。Dockerは独自のクラスタサポート機能だけでなく、Kubernetesネイティブの統合機能を追加した。Kubernetesを管理する団体Cloud Native Computing Foundation（CNCF）の憲章は、「適切なセキュリティと分離を備えるコンテナ普遍主義」を主張している。これはVMにとって脅威をもたらすものだ。CNCFが掲げる原則によって、Dockerが推奨するKubernetesアプリケーション用の標準マニフェストが持つべき特徴が確立される。コンテナ普遍主義があることによって、クラウドベンダーは自社のコンテナホスティング製品を差別化するためにさらなる取り組みを推進しなければならないというプレッシャーを感じている。

正しいVMの使い所

　KubernetesはVMを利用することでクラウドに導入できる。そうした側面を理由に、コンテナ増加がVMに与える影響は限定的だと考えられるかもしれないが、いずれにせよ全てはエコシステムに帰着する。VMの価値はその普遍性にある。一方コンテナの価値は、アプリケーションの導入方法や接続方法を標準化し、制約を設けられるエコシステムにある。Kubernetes関連のコンテナツールは多数存在し、これらのツールを使えばエコシステムの範囲はさらに広がる。そうした拡大によって、VMが提供する汎用的な導入オプションの価値はさらに限られてしまう。

　VMがあれば、その中でエコシステムを稼働させることは可能だ。それがコンテナのようなエコシステムだったとしてもだ。ただしそうしたアプローチは、コンテナとVMを差別化するほとんどの機能を無意味にする。VMの方がコンテナよりも秀でている機能は、セキュリティと分離だけになってしまった。その上、これらの差別点はCNCFのような団体やAWS、Google、Microsoftのような企業のターゲットになっている。

　サーバレスコンピューティングを実現するには、安全で分離されたホスティングが必要だ。新しいホスティングモデルがなければ商業的には生き残れない。そうしたモデルはサーバの仮想化というよりも、コンテナ化に近い。

　企業のシステムアーキテクトやIT部門のディレクターは、アプリケーションをコンテナエコシステムのモデルに沿うように移行する作業に着手すべきだ。自社のホスティングをコンテナ重視に切り替える計画を立てる必要がある。それと同時に、サーバレスコンピューティングの進化にも注意を払うことが欠かせない。