まず第1に、単一のコンテナ管理戦略を採用する必要がある。Dockerは最も人気の高いコンテナアーキテクチャだが、他にもCanonicalの「LXD」といった選択肢がある。コンテナの移植は、クラウドとデータセンターを通じて同じコンテナアーキテクチャを使うことで実現される。つまり着手する前に、全ホスティングオプションで確実に機能する単一のコンテナ戦略を立てる必要がある。最も幅広く採用されているコンテナシステムのDockerはそうした理由から、自ずとアプリケーションの移植を望む場合の選択肢となる。

　第2の手順として、デプロイを標準化するために付加的なコンテナツールを採用する必要がある。大規模なDockerデプロイは、ほぼ全てがコンテナの管理と通信のためにDocker管理ツール「Kubernetes」を使っているが、「Shipyard」も検討できる。開発担当者と運用担当者が連携してアプリケーション開発を進める「DevOps」のツールを使っている場合、自分のパッケージがコンテナのデプロイに対応していることを確認する必要がある。DevOpsのインフラ構成をコードで管理する「Infrastructure as Code」機能を使って環境に依存しないコンテナを作成しデプロイする。Docker管理ツール「Docker Compose」は、純粋なコンテナのデプロイに対応できるが、ほとんどのユーザーはすぐにはそこまでは到達しない。

　第3に、コンテナセキュリティを体系化し、その仕組みを社内の全環境を通じて標準化する。コンテナは仮想マシン（VM）ほど安全ではない。パブリッククラウドにコンテナをデプロイする場合、セキュリティ対策に気を配るのであれば、公開コンテナサービスを使うよりも、専用サーバかVMを使ってコンテナシステムをホスティングすることを検討した方がいい。セキュリティを強化するのなら、Dockerにも独自の仕組みとして「Docker Content Trust」が登場した他、サードパーティーのセキュリティツールやブロックチェーン技術を利用するものなど多数存在する。アプリケーションの移植を追求するのなら、そうしたツールの採用には一貫性を持たせなければならない。

　第4に、ログを移植可能な方法で一元化する。コンテナシステムはログが追跡できなくなりやすい。複数のクラウドやデータセンターを横断してデプロイしている場合はなおさらだ。「LogSpout」のようなツールを使えば少なくとも、ログを一元化し、何が起きているかを整理して参照できる。

　最後に、「Flocker」のようなツールを使ってデータベースとボリュームを管理する。コンテナの移植は、データベースの利用や配置における相当の効率悪化につながることもあり、移植性が高まるほど、問題も大きくなりやすい。場合によっては、データベースへのアクセスを一元化するために、コンテナを使ってデータベースクエリサービスをマイクロサービスとしてホスティングしたいと思うかもしれない。だが、跨いでいるネットワークが多すぎて反応時間に多大な遅延を生じさせないよう注意しなければならない。

　ITプロフェッショナルの多くは、アプリケーション移植を実現するためにこうした条件を全てコンテナに適用することと、同じ条件をVMに適用するのとそれほどの違いはないと気付くだろう。だが単純にVMあるいはIaaS（Infrastructure as a Service）と、マシンイメージを構造化して移植性を確保し、DevOpsツールを使ってデプロイプロセスを標準化できるだろうか。

　バージョン管理とデプロイの規律は、IaaSやVMでのマシンイメージの移植とデプロイをしやすくさせるが、根底にあるホスティングの効率性に問題は残る。コンテナシステムと違って、ソフトウェアバージョン管理の厳格性を緩めても直接的な悪影響はない。だが一時的に大量のトラフィックが発生して起こる「クラウドバースト」を試みる場合や、別のプラットフォームにフェイルオーバーしようとする場合のみ、問題が生じるかもしれない。

　ほとんどのエンタープライズクラウドユーザーにとってコンテナは、クラウド間の移植を問題なく実現するアプリケーションの開発に向けた前向きな1歩となるだろう。コンテナと強固なDevOpsを組み合わせ、クラウドリソースの定義と設定にInfrastructure as Codeを利用すれば、ホスティング場所に対するアプリケーションコンテナの透明性を大幅に高めることができる。そして、クラウドアプリケーションの耐久性と反応性を高め、維持費を削減することができるだろう。