クラウド回帰がパブリッククラウドからオンプレミス環境への単なる移行以上の意味を持つ理由

企業がクラウドに移行した後、一部のワークロードがクラウドでは動作しないことが判明した場合、どうなるでしょうか?その答えはクラウドへの回帰です。これは近年ますます人気が高まっている戦略で、企業の 80% が、現在パブリック クラウドでホストしているワークロードの少なくとも一部を回帰させる計画があると報告しています。

[[341152]]

一見すると、このような統計は、大量の負荷をオンプレミスに戻すことを正当化する証拠として見られるかもしれません。しかし、現実には、クラウドの回帰ははるかに複雑で微妙な問題です。多くの場合、これは企業がパブリック クラウドを導入する前に使用していたオンプレミス構成を再導入することではありません。新しいハイブリッド クラウドの機会を活用したり、オンプレミスのワークロードをパブリック クラウド サービスと統合するより優れた方法を見つけたりすることが重要になります。

クラウド回帰の意味、それがなぜ人気のトレンドになったのか、そして最も効果的なクラウド回帰戦略を開発する方法について学びます。クラウド回帰戦略では、クラウドに移行する前に依存していた社内インフラストラクチャを再構築する以上の作業が必要になることがよくあります。

クラウドの帰還とは何ですか?

簡単に言えば、クラウドの復帰とは、現在パブリック クラウドで実行されているアプリケーションまたはデータをパブリック クラウド外のインフラストラクチャに移動するプロセスです。

たとえば、企業は Amazon EC2 や Azure Virtual Machines などのサービスで仮想マシンをホストし、その後それらをオンプレミスのデータセンターに移行する場合があります。あるいは、企業はパブリック クラウドで実行されている SaaS アプリケーションを、プライベート クラウドまたはハイブリッド クラウドでホストされているアプリケーションに置き換えることもできます。

企業がクラウドへの回帰を選択する理由はさまざまです。これは、クラウド コンピューティングのコストが実際には予想よりも高額であると判断することから、クラウドが必ずしも特定のニーズを満たしていないと判断することまで多岐にわたります (バックアップとリカバリなど、クラウドベースのコンピューティング バックアップをオンライン バックアップに復元するには時間がかかる場合があります)。

帰国がクラウドコンピューティングに及ぼす影響

クラウド回帰については、より多くの組織がオンプレミス モデルに移行し、クラウド アーキテクチャの重要性が低下するだろうと簡単に想定できます。

しかし現実はもっと複雑です。一部の組織にとって、クラウドへの回帰は単にワークロードをオンプレミス モデルに戻すことを意味しますが、他の組織では、クラウドを完全に放棄するのではなく、より複雑なタイプのクラウドベースのアーキテクチャへの移行が必要になります。

たとえば、クラウド ワークロードを復帰させる次の方法を検討してください。

• 従来のパブリック クラウドでホストされていた SaaS アプリケーションをエッジ コンピューティング モデルに移行します。エッジ コンピューティング モデルでは、アプリケーション自体はパブリック クラウドに残りますが、データ処理はオンプレミス サーバーで行われるため、パフォーマンスが向上します。この場合、ワークロードの 1 つの側面のみが返されます。
• バックアップおよびリカバリ操作の拡張により、バックアップ データ ストレージはかつてはパブリック クラウドのみに依存していましたが、現在はオンプレミスだけでなくクラウドにもバックアップを保持できるようになり、組織にさらに多くのリカバリ オプションが提供されます。この例では、もともとパブリック クラウドでのみ実行されていたワークロードがオンプレミスのリソースも消費するようになったにもかかわらず、技術的にはクラウドへの復帰は発生していません。
• コンプライアンス要件を満たすために、企業は Azure Stack や AWS Outposts などの次世代ハイブリッド クラウド フレームワークを活用して、以前はパブリック クラウドで実行されていたワークロードをオンプレミス サーバーに移行しています。ワークロードは引き続きパブリック クラウド サービスに依存しますが、オンプレミスでホストされるため、コンプライアンスの課題が簡素化されます。

これらの例では、クラウド コンピューティング アーキテクチャは、クラウドの回帰が行われる前よりも複雑になっています。かつてはパブリック クラウドのみを対象としていたアーキテクチャは、ハイブリッド モデルまたはエッジ モデルに進化します。

クラウド復帰のベストプラクティス

組織がパブリック クラウド戦略に満足しておらず、一部のワークロードを本国に戻すことを検討している場合は、次のヒントに留意してください。

• クラウドの復帰は撤退ではありません: 前述のように、多くの場合、クラウドの復帰は、パブリック クラウドを導入する前に使用されていたアーキテクチャ モデルに戻ることではありません。むしろ、より複雑なアーキテクチャを使用してパフォーマンス、コスト、またはその他の要素を改善する手段です。
• ビジネスが複雑さに対処できることを確認する: クラウドの回帰では、パブリック クラウドとオンプレミスのリソースを統合することでアーキテクチャが複雑になる傾向があるため、追加の管理負担に見合う価値があるかどうかを確認します。ストレージや仮想マシンにかかる費用を数ドル節約するために、ワークロードのクラウドベースとオンプレミスの両方のコンポーネントを監視する価値はあるでしょうか?そうかもしれません。しかし、本国送還の波に乗る前に、これらの考慮事項を評価してください。
• ワークロードを移植可能に保つ: 新しい目標を達成したり、新しい機会を活用したりするために、アーキテクチャを再度変更する必要があるかどうかはわかりません。したがって、クラウドへの復帰を実行するときは、将来必要に応じて簡単に移行できるように、ワークロードを移植可能な状態に保つための努力が必要です。
• パブリック クラウドの将来について考える: 企業は、より複雑になるような方法でワークロードを本国に戻すことを決定する前に、単にパブリック クラウドに残しておくことが最善の長期戦略ではないかどうかを真剣に検討する必要があります。ここで特に重要な考慮事項は、パブリック クラウド サービスは時間の経過とともにより安価になり、より強力になっているということです。したがって、パブリック クラウドは、現在の特定のワークロードにとって理想的なソリューションではないと主張されているとしても、将来的にはより優れたソリューションになる可能性があります。企業は、元のパブリック クラウド アーキテクチャを今後 1 ～ 2 年間維持した方が良かったと判明するだけの面倒な作業は望んでいません。

結論は

組織がクラウド コンピューティング戦略を再評価するにつれて、ほとんどのリソースが本国に回帰される可能性が高くなります。しかし、クラウドの強制退去を単にクラウド以前の時代への時間を先送りする手段として捉えるのではなく、より堅牢なアーキテクチャを構築する機会として捉えた方がよいでしょう。