Webサービスの互換性問題は2種類ある。1つは、複数のベンダーが本質的に同じサービスを提供しているものの、APIが異なっている場合である。これは比較的小さな問題だ。面倒だが、アプリケーション全体のアーキテクチャには影響しないため、回避するのはそう難しくない。

　もう1つの問題はより厄介で、クラウドベンダーがサービスをそれぞれ独自に構築している場合だ。最初の問題のように、API呼び出しを変更するだけではなく、アプリケーション設計全体の変更が必要となることもある。

　さて、互換性の問題をどう回避すればよいのだろうか。解決策は3つある。

1．クラウドバースト、フェイルオーバーに備えたアプリケーションコンポーネントの分離

　クラウドバーストまたはフェイルオーバーが起きると予想できるようなアプリケーションコンポーネントは、複数のクラウドに分離し、Webサービスを統合しないようにする必要がある。これが問題となる理由は、アプリケーションのフロントエンドコンポーネントにはWebサービスを使用するのが一般的なためだ。しかし、マルチクラウド化を推進するアプリケーションでは、Webサービスに依存する部分をポータブルまたはスケーラブルにすることは難しい。

2．ベンダー固有のWebサービス利用を回避

　第2の選択肢は、クラウドベンダーのWebサービスより優れている、互換性が高くて一般的な業界標準ミドルウェアを利用することだ。例えば、パブリッククラウドサービスのほとんどでホスティング可能な、互換性のあるサードパーティー製品やオープンソース製品がある。ただし、これらの製品がクラウドインフラと必ずしも密に統合できるとは限らないため、スケーラブルなWebフロントエンドやデータベースなど独自のアーキテクチャモデルを開発する必要がある。

　この方法を選択する場合は、オープンソースクラウドとコンテナ技術を慎重に評価し、「OpenStack」「Kubernetes」「Apache Mesos」「Marathon」のパッケージ化された実装を使用してオープンなWebサービスツールキットを構築できるかどうかを確認する。仮にパッケージに必要なものが全て含まれていない場合でも、マルチクラウド戦略のための普遍的なホスティングフレームワークとしては役に立つ。

3．アダプターの利用

　最後の選択肢は、Webサービスの周辺機能としてアダプターを開発し、各アプリケーションと互換性を持たせる方法だ。同様のWebサービスを提供する複数のパブリッククラウドベンダーを、異なるAPIを使って利用する場合、アダプターパターン（互換性のないインタフェースを持つクラス同士を適合させるデザインパターン）を使用することにより、複数のAPIをアプリケーションが使用できる単一の共通APIに変換できる。

　ベンダーとベンダーのWebサービスの相違点がAPIとデータモデルのみの場合、これは比較的容易だ。しかし、Webサービスにアーキテクチャの相違点がある場合は、それらを抽象化して、共通するアダプターのAPIで完全に表現できるようにする必要がある。設計する前に、特定の機能に関連付けられている全てのWebサービスAPIの詳細を確認することが重要だ。

　マルチクラウド戦略における互換性問題を最小限にする3つの戦略には、それぞれ適した対象がある。大企業ではこれら3つの戦略全てを利用する必要があるかもしれない。しかし長期的に見れば、第3の選択肢が最善のアプローチである可能性が高い。クラウドベンダー間の競争は激化しており、各ベンダーが将来をどのように見ているかによって、Webサービス間の格差は次第に広がっていく。その格差を超える最も標準的な手法があれば、その手法こそが市場で普及するだろう。