AWSにとって、AWSのサービスで全て完結できると宣言する顧客をもっと増やそうとする取り組みにマルチクラウドはそぐわない。Microsoftも同じような考えと思われるが、一方でマルチクラウドは一部の組織にとって比較的短期的な戦略になるかもしれないと考えている。

　Microsoftのクロスドメインソリューションアーキテクト、ジョン・M・クラーク氏は2018年10月、ブログに次のように記した。「われわれの考えでは、組織はいずれ中心的なクラウド事業者を選び、それを使い続けてサービスとエコシステムをフル活用する公算が高い。何よりも、そのクラウドのPaaSやSaaS、FaaS（Function as a Service）を全面的に活用できるように、アプリケーションが現代化され、あるいはリファクタリングされている」

　「時間と人材の両方に投資できる規模があるのなら、複数のクラウドに落ち着く企業もあるだろう。そのクラウドが、そのワークロードにとって価値のある差別化を実現しているのであれば、それは合理的だ。だがそれは、両方について深く掘り下げることができ、それぞれが提供するPaaSサービスを活用できる場合に限られる」

マルチクラウドはコンテナから

　それを考えると、Googleがパブリッククラウド大手3社の中で最初にマルチクラウド管理プラットフォームを製品化したこと、GoogleのクラウドとAWSおよびMicrosoftがホスティングする環境間でワークロードを移動させる企業の支援に乗り出したことに、意外性はないのかもしれない。

　Googleの「Anthos」は、オープンソースソフトウェアで構築されている。中でも特筆すべきはコンテナオーケストレーションエンジンの「Kubernetes」だ。これは「Google Kubernetes Engine」（GKE）の一画を構成する。

　GKEのマネージド環境では、企業が自前のKubernetesクラスタを事前に構築しなくても、コンテナ化されたアプリケーションをオンプレミスとクラウド環境で運用できる。

　Anthosのコンテキストでは、企業が移植性を目的に自分たちのアプリケーションや仮想マシンをコンテナ化して、AWS、Google、Microsoftのクラウド間を移動させることができる。

　公共セクターにフォーカスしたクラウド事業者UKCloudのCTO（最高技術責任者）、レイトン・ジェームズ氏によると、どんな組織であれ、複数のクラウドを横断するワークロードの移植性を追求する場合はまずコンテナについて調べる必要がある。

　「例えばRed HatのOpenShiftはDockerとKubernetesをベースとするプラットフォームで、AWS、Google、Microsoftおよび他のクラウドを横断して運用できる」とジェームズ氏。

　「多くの組織は、1つのグローバルクラウドプラットフォームをネイティブに導入する。その場合、主に2つの選択肢がある。VMwareとMicrosoftは、ワークロードをパブリッククラウドからプライベートスタックに移行させるためのツールを提供している。他にもデータ複製・移行ツールを提供するZertoのようなサードパーティーツールがある」

マルチクラウドを機能させる

　ITコンサルタント企業World Wide Technology（WWT）の欧州、中東、アフリカ（EMEA）担当最高技術アドバイザー、デイブ・ロック氏によると、パブリッククラウド業界の関係者が信じたがっていることとは裏腹に、ユーザーが例えばAWSのサービスを補うためにAWSと競合する企業の技術を使いたいと思う理由は確実にある。

　「クラウド事業者はそれぞれ得意分野が異なる。AWSはコンシューマーソリューションに優れ、Microsoftの長年の歴史に支えられたAzureは法人と相性がいい。Google Cloud Platformにはビッグデータの優秀な分析ツールがある」

　「企業はそうした異なる強みを理解して、自分たちの目標と照らし合わせる。そうすることで、自分たちが理想とする（マルチクラウド）導入の姿を描くことができる」

　金融サービス会社のHSBCとKeyBankはいち早くAnthosを採用した。

　WWTのロック氏によると、マルチクラウドの導入は、1社ではなく複数ベンダーのツールや技術を使いこなせるだけの深い知識や経験を持った人材の確保が障壁となる。

　「ほとんどの企業は、自分たちのオンサイトサーバやプライベートでホスティングしているソリューションに対応するスキルは非常に高い。だがパブリッククラウドの利用となると、重大な知識の溝がある」とロック氏は言う。

　「ほとんどの企業には、複数のパブリッククラウドを伴う環境をうまく構築するためのスキルもリソースもない。成長し続けるパブリッククラウドの性質は、同様に流動的な課題を社内チームに投げ掛ける」

　UKCloudのジェームズ氏によると、マルチクラウド環境を管理するための適切な人材の確保に当たっては、その企業が既に社内で持っている経験に基づいてスキルを開発し、積み上げることから始めるのが最善だ。

　結局のところ、クラウドに関するスキル不足は周知の通りであり、マルチクラウドを実現できる人材を追い求める道を選ぶことは徒労に終わるかもしれない。

　「複数のワークロードに対応する鍵は、VMwareやOracle、Cisco Systemsといった企業の技術に取り組む中で得た、チームの既存のスキルや経験、知識を活用することにある」とジェームズ氏は指摘する。

　「DevOpsやアジャイルのような新しいアプローチを徐々に採用することによって、企業のデータセンターを着実に近代化することの方が、そうした全てを一気に取り入れることよりも望ましい。一気に取り入れたために問題が起きることもある」

マルチクラウド管理問題

　3つの異なるクラウドを管理しなければならないことに加え、複数ベンダーの請求書をどうやりくりするかを考え、セキュリティポリシーに関して起こり得る変更に常に目を光らせ、そうした環境で運用しているワークロードに常に最適化されていることを確認する必要もある。

　加えて、プロバイダーがプラットフォームに追加するあらゆる新機能を把握しておくというプレッシャーものしかかる。大手3社とも、変更や新サービスを打ち出すことに関しては手を緩めない。

　マルチクラウド採用にゴーサインを出そうとするIT部門は、どこの技術がどのクラウドで何をするかのスピードに付いていくことが課題になる。RackspaceのEMEA担当CTO、リー・ジェームズ氏はそう話す。

　Rackspaceはパブリッククラウド市場の成熟に伴い、ここ数年で大きく変化した。この間に同社はIaaS市場においてAWS、Microsoft、Googleのライバルでいることから軸足を移し、管理サービス製品を打ち出すことでコラボレーターとなった。

　Rackspaceのジェームズ氏によれば、Rackspaceの顧客の約10％は1つのプライベートクラウドと2つ以上のパブリッククラウドを組み合わせた環境を運営している。そうした顧客がこの環境を機能させるための最大級の課題は、あらゆるイノベーションに追い付くことだという。

　「マルチクラウドの運用で最も一般的な課題は管理に関するものだ。常に何千ものアップデートが行われるさまざまなベンダーを横断して、何を獲得できるかに目を光らせ続けなければならない」

　「AWSは前四半期だけで400以上の製品をアップデートした。自社のマルチクラウドを横断してそれを推定すると、管理すべきことは多い。それが『カササギ効果』とわれわれが呼ぶ現象につながる。製品リリースの多さのために、企業は常に最新のアップデートを追求しなければならず、結果として中核的なニーズが見えなくなる」

　マルチクラウドには、クラウドベンダーが提供する最新かつ最善の技術をはるかに簡単に利用できるという付加価値もある。Canonicalのファーベル氏は言う。

　「イノベーションの分野はベンダーによって異なる。マルチクラウドを採用する企業は、それが利用可能になり次第、活用できる。特定のベンダーに依存する企業は、そのベンダーが他社のイノベーションに追い付くのを待つ必要がある」

　ロック氏によると、クラウドを横断して導入される新機能に追い付くだけでなく、問題や障害が起きたときにそれを確実に把握するためのシステムを導入する必要がある。

　「複数のクラウドの監視は継続的な課題になる。これは問題や障害の修正にとどまらない。企業は不具合の発見に努め、ビジネスに重大な影響が出る前に問題を阻止しなければならない」（ロック氏）

　「適切に管理していれば、これは簡単に達成できる。だが実際に運用を始めてみるまで、その環境がどう機能するかを真に理解することは難しい」

　この種の問題を避けるための対策の一つとしてSoftwareONEのダルグリッシュ氏が挙げるのは、マルチクラウドを構成する各プラットフォームの仕組みについて高い可視性を提供する管理レイヤーを調達することだ。

　「企業は、CIO（最高情報責任者）がリアルタイムでスピードや性能を見通すことのできる包括的な管理レイヤーを必要とする。IT部門も、コントロールされた管理プロセスが徹底されていることを確認し、事業部門が求める新しいクラウドサービスの調達をコントロールしなければならない。そうした手順を踏めばITチームの負担が軽減され、相当なクラウド投資の費用対効果（ROI）を実現する」（ダルグリッシュ氏）

　あらゆる要素を検討すると、一部の組織にとってマルチクラウドは価値よりも負担の方が大きいという結論に落ち着くかもしれない。関連する管理上の負担が増えたとしても、コストやパフォーマンス、耐久性の向上といったメリットが上回るのかどうかについて、自分たちで検討する必要がある。