常により良い製品を迅速に構築できるようにするには、信頼性の高いクラウドソリューションを使用して、急なニーズが生じた場合でもすばやく拡張して対応できるようにする必要があります。クラウドコンピューティングを単一のベンダーに依存している組織は、クラウドサービスプロバイダーが需要の急増に対応できなければ、ダウンタイムとデータ損失に見舞われる恐れがあります。顧客は信頼でき、停止期間の少ないアプリケーションを求めているため、単一のクラウドに依存するのは、ビジネス上のニーズと市場における需要の両方に応えようとしている組織にとって、リスクを伴う決断となります。
サービスの停止は発生するものですが、顧客を失わないためには、発生頻度を最小限に抑える方法を特定しなければなりません。マルチクラウドアプローチでは、Google Cloud PlatformやMicrosoft Azure、Amazon Web Servicesなどの複数のクラウドソリューションでコンピューティングを行うことで、データの損失とダウンタイムの発生のリスクを軽減します。
クラウドコンピューティングにおけるマルチクラウド戦略とは、単一のネットワークアーキテクチャ内で、異なるクラウドベンダーが提供するクラウドコンピューティングサービスを2つ以上使用することを指します。マルチクラウドをデプロイすることで、チームはあらゆる技術的ニーズとビジネス上のニーズに最適なプロバイダーを選択できます。マルチクラウド環境では、利用可能なストレージおよび処理能力が増加し、さらにコスト削減が促進されます。組織は、同じタイプのクラウド（パブリックまたはプライベート）を複数デプロイすることで、最適なクラウドソリューションを活用できます。
プライベートクラウドはある組織の専用の環境であるため、セキュリティとコンプライアンスを確保するために特定の方法でプロビジョニングすることができます。プライベートクラウドは、Platform as a Service（PaaS）として販売されているか、もしくはInfrastructure as a Service（IaaS）として提供されています。パブリッククラウドは、クラウド環境を共有する複数の顧客に対してクラウドソリューションを提供します。自動的にプロビジョニングされるため、安全性が低く、取り扱いに注意を要する機密データを格納するのには適してないと考えられています。
マルチクラウド戦略におけるCI/CDの重要性について学ぶ →
組織の約85%がマルチクラウド環境を使用しているものの、どの組織も同じ成熟度に達しているわけではありません。チームがマルチクラウドの成熟度モデルを進むにつれ、抽象化レイヤを介して、プロセッサーやOS、仮想ソフトウェアなどの基盤となるインフラストラクチャからクラウドサービスが分離され、移植性が向上します。
単一のクラウド
すべてのアプリケーションを単一のクラウド内に置きます。この戦略では、企業は使いやすさを重視したためか、または提供されるサービスが現時点でのビジネス上のニーズを満たしているために、単一のクラウドプロバイダーですべてを監理します。組織は、単一のベンダーに縛られることになります。
移植性なし
同じ組織内に複数のチームが存在し、それぞれが異なるクラウドプロバイダーを使用しています。各チームは、独自の単一のクラウド環境で作業しています。この構造では、複数のクラウドが使用されているものの、厳密にはマルチクラウドとは言えません。
ワークフローの移植性
ワークフローの移植性が確保されていれば、どこにでもデプロイできます。デベロッパーは、特定のクラウドにワークフローを合わせずに済みます。その代わりに、クラウドに依存しないDevOpsプロセスとデプロイに関する意思決定を行うためのフレームワークと一緒に、単一のワークフローを使用できます。
アプリケーションの移植性
このシナリオでは、アプリケーションを任意のクラウドで実行できます。またクラウド固有のサービスは抽象化されます。抽象化のためにエンジニアリングインターフェイスが必要となるため、アプリケーションの移植性を達成することは困難です。また、組織はすべてのクラウドに共通する機能しか使用できないため、プロセスを改善しうる特殊な機能を活用する機会を逃すことになります。
ディザスタリカバリの面での移植性
このシナリオでは、短いダウンタイムで、アプリケーションを別のクラウドにフェイルオーバーできます。クラウドプロバイダーのデータセンターがダウンしたとしても、別のプロバイダーに切り替えられます。
ワークロードの移植性
ワークロードの移植性に関して組織が目指すところは、アプリケーションのワークロードを複数のクラウド間で動的にシフトさせることです（例：バックグラウンドジョブの処理のためにサーバーをオートスケールさせる）。ワークフローの移植性を確保できれば、ビジネスサービスの一部分を適切なインフラストラクチャに移行でき、ユーザーのニーズに対応できます。
データの移植性
データの移植性とは、ユーザーがサービスからデータを取得でき、大抵の場合はAPI経由でそのデータを転送または「移植」できることを意味します。
継続的インテグレーションでは効率性が重視されており、効率的にするために、以下の要素を中心に構築されています。
優れた柔軟性
どのクラウドベンダーもある部分では優れているものの、別の分野では競合と比べて劣っているものです。複数のベンダーを利用できることで、組織は対象業務に適したツールを使えます。
ワークフローの移植性
プロジェクトのデプロイ先を問わず、同一のワークフローを利用できます。
優れた回復力
複数のクラウドプロバイダー間でのフェイルオーバー構成を設計することで、いずれかのベンダーがダウンした場合でも、稼働を維持できます。
クラウドに関する交渉の改善
DevOpsプロセスがベンダー固有のサービスに依存していないため、別のクラウドベンダーからさらに良い条件や大幅なクレジットの付与が提示された場合に、より有利に交渉を進められます。
