価値やイノベーションを選んだ場合、究極的には選択肢の減少に結び付く。そうしたサービスや一貫性のなさが原因で、現在の移植可能性は発展途上にある。この移植性の課題には、クラウドサービスのバーストやブローカーといった、より積極的な動きも含まれる。

　移植性は2つのカテゴリーに分類できる。第一に挙げられる1回限りの移動では、クラウドベースのアプリケーションをある事業者や環境から別の事業者へと切り替える。ワークロードを元に戻す意図はない。移植性の第二の形態では、頻繁な移動が求められる。この場合、クラウド料金のリアルタイムの変動、あるいは自社の現在のインフラ利用に応じて、2つの事業者の間、または同じ事業者の導入環境の間で、クラウドベースのアプリケーションを手早く移動する必要がある。

一般的な1回限りの移動

　ある事業者から別の事業者への移植性は、クラウドの導入後間もない組織に共通する需要であり、現在のツールやテンプレートの変換によって十分に達成できる。難しいのは、単一のクラウド事業者にしかないサービスを活用している複雑なアプリケーションのマッピングだ。さまざまなサービスやテンプレートでがんじがらめになったパブリッククラウドのヘビーユーザーは、真に囲い込まれた状況にある。それでも多くは、料金が一貫していてその製品の価値が高いことに満足している。そうした状況が変わったとき、あるいはもし変われば、従来の事業者から別の事業者への切り替え需要は高まる。

　1回限りの移動にまつわる現状には多くの問題がある。まず、テンプレートが一致しない。クラウド事業者は、それぞれ独自の形式やツールを使ってアプリケーションやインフラテンプレートを作成しており、その多くは同じ事業者のパブリッククラウドとプライベートクラウドの間でバージョンが異なる。ワークロードを移行するためには、従来事業者のテンプレートを、新しいクラウド環境の同等のテンプレートへと変換しなければならない。

　支援サービスやサプライヤーが提供するツールは、フォーマット間では基本的なクラウドサービスを移行する助けになるかもしれない。だが、サービスと組み合わせたもっと複雑なアプリケーションの場合、変換の過程で価値が大幅に落ちることもある。Distributed Management Task Force（DMTF）のオープン仮想化フォーマット（OVF）や、TOSCA の Oasisといった標準化の取り組みは、将来的な相互運用性の実現のために、仮想マシン（VM）をベースとするソフトウェアのパッケージングフォーマットの標準化を目指す。それぞれの標準技術が、いずれはもっと移植性の高い未来を実現するだろう。しかしサプライヤーは、繰り返し可能な移植性のために従うべき一貫したテンプレートを持たない。

　2つ目の問題は、サービスとエコシステムの一貫性のなさにある。基本的なストレージと演算機能は、新しいクラウドサービスへ簡単にマッピングして移転できる。ネットワーク構成には時間がかかることもあり、大部分が手作業になるが、これはサプライヤーの支援でこなせることも多い。真の問題となるのは基本的なプロジェクト以外のサービスとエコシステムだ。

　サービスとエコシステム事業者の価値は大きい。こうした事業者はソリューションを強化し、同等の基本的なソリューションでさえも、構築に必要な時間を大幅に短縮してくれる。各サービスはその事業者特有のものであり、その利用はその事業者への依存を意味する。しかし、ほとんどのユーザーは、特定のパブリッククラウド事業者についての見識を持たず、特定のサービス間の違いに関する変曲点を見極めることができない。最先端の企業はそうした変曲点を理解しているだけでなく、そのソリューションから離れることに伴う総コストとその価値を比較して、入れ替える価値があるかどうかを判断できる。

　クラウド事業者の間でコンテナの成熟性が欠如していることも、もう一つの共通の課題として挙げられる。コンテナは新しい概念ではない。

「Docker」のようなシステムレベルソリューションの運用を後押しする機運は、使いやすさや、「Linux」を搭載するどんなシステムにも対応できる応用性、アプリケーションの移植性に対応できるタイミングの良さから発展してきた。コンテナはステートレスな状態でアプリケーションをパッケージングして、基盤となる環境からの抽象性を確立できる。これによって移植性を実現する半面、課題も生じさせる。ワークロードが条件を満たし、ポリシーに従うためにはコンテキストを必要とする。他の補助的な移植性の取り組みは、コンテナが全体としてステートレス状態を保ちながら、エンタープライズワークロードに必要なコンテキストを提供する助けになる。自社のクラウド移植においてもコンテナが役割を果たす公算は大きい。だが、セキュリティはまだ発展途上であり、長期的なコンテナ事業者はまだ確立されていない。

　この市場はこれからも大きな変動が予想される。これまでの利用は主に、開発サイクルの中のテスト段階や、そうしたワークロード関連の開発を容易にすることを目的としたモノリシックなレガシーアプリケーションのパッケージングに限られていた。

移行に向けた最後の課題は、アプリケーションの粘着性に足を取られることだ。どのクラウド事業者も、顧客が離れることは望まない。それでも主にインフラに重点を置く事業者であれば、そのサービスから比較的簡単に離れるチャンスはある。もっと優れたクラウド事業者は、アプリケーションレベルで顧客を囲い込む。もし自分たちのアプリケーションで、Amazon Web Services（AWS）が提供する「Lambda」や「Simple Notification Service」といったサービスのいずれかを使っていた場合、AWSから別のクラウドプラットフォームへ移行できる見込みは極めて小さい。顧客はそこにはまり込んだ状態にある。

　他のクラウドプラットフォームにも同じことがいえる。これは必ずしも悪いことではないものの、アプリケーション開発者がそうしたサービスを使っていれば、囲い込まれた状態は続く。これは、移行や移植に関する意思決定を左右する。

頻繁な移動はまだ実現せず

　クラウドバーストやクラウドブローカーの可能性について考えるのは楽しい。だが法人顧客の前には多くの障壁が立ちはだかる。ワークロードの動的な移植は興味深いコンセプトだが、まだ検討課題にはならない。ブローカーは、その時点で最もコストが安いプラットフォームにクラウドワークロードを動的に移動させる。一方、バーストは、どんな時点においてもアプリケーションのコストとパフォーマンスを最適化することを目指す。企業は平常の利用時には自前のVM環境で持続的な利用のための料金を支払い、追加的な容量が必要とされるときはパブリッククラウドリソースを使うことができる。

　ブローカーは初期の導入時に限られる。2011年の時点で、コストやパフォーマンスのリアルタイムの変動に応じてクラウドサービスを動的に調達して移動するというアイデアは、従量制クラウドの料金体系戦略の未来構想だった。そして今も構想であり続けている。

　今は最初のツールが登場してきたばかりで、用途も限られる。単純に言って、強いブローカー需要を生じさせるほど、パブリッククラウドのコスト間に大きな違いはない。基本的なテストやサンプルを想定したリアルタイムの情報需要に対応することは、初期導入においては自らのクラウドアドバイザーとしての責任を果たす支えになるかもしれないが、既にプロビジョニングされたワークロードの移植を支える役には立たない。1回限りの移行の足かせとなる制約もまた当てはまる。ブローカーツールは戦略的に適切な調達を支援することはできても、移植性を支援することはできない。

本稿はローレン・E・ネルソン、チャールズ・ベッツ両氏によるForresterの2017年第4四半期報告書「The state of cloud migration, portability and interoperability」より抜粋。