パブリック クラウドは長年にわたって存在していましたが、組織は依然としてデータ センターで実行されているアプリケーションをパブリック クラウドに移行する取り組みを続けています。場合によっては、従量制の価格設定を利用するためにアプリケーションを移動する必要があるかもしれません。また、クラウドによってアプリケーションの拡張や最新化が容易になる場合もあります。あるいは、新しいデータセンター ハードウェアの出費を避けたいだけです。
しかし、クラウドへの移行を決定することと、実際に実行することの間には大きな違いがあります。一部のアプリケーションは比較的簡単に移動できますが、他のアプリケーションは非常に難しいことで知られています。さらに、クラウドへの移行にはさまざまな種類と方法があります。
7 つの R モデルは、それらを覚えるのに役立ちます。
なぜ 7 つの R なのでしょうか?
R’s モデルは新しいものではありませんが、長年にわたって大幅に進化しています。その起源は通常、5 R モデルを考案した Gartner に起因すると考えられています。 2010年に遡ります。元の 5 つは、再ホスト、リファクタリング、改訂、再構築、置換でした。
クラウドが進化し続け、より多様なワークロードがクラウドに移行されるにつれて、AWS は 6 番目の R を追加しました。 引退する — そして最終的には 7 番目の、 保持。この 7 番目の R は、事実上、すべてのワークロードがクラウドでのホストに適しているわけではないことを認めていることになります。
7 つの R がそれぞれ実際に何を意味するのかを次に示します。
各 R は、オンプレミス アプリケーションをクラウドに移行する必要があるかどうか、およびその最適な方法を決定するためのいくつかの標準的な方法の 1 つを示します。
1. 再ホスト
リホスティングはよく次のように呼ばれます。 持ち上げてシフトする。これには、アプリケーションをそのままクラウドに移行することが含まれます。
再ホストはいくつかの方法で実行できますが、多くの場合、アプリケーションが現在実行されているインフラストラクチャを模倣するクラウドベースの仮想マシンを作成することになります。クラウド インフラストラクチャはオンプレミス インフラストラクチャと非常に似ているため、アプリケーションをクラウド内の新しいホームに移動するのは比較的簡単な作業になります。たとえば、一部の組織では、アプリケーションの仮想インフラストラクチャをクラウドに構築し、バックアップを新しいクラウドベースのインフラストラクチャに復元することでアプリケーションを再ホストしています。通常、移行後には、アプリケーションが新しい場所でアクセスできるようにするための DNS レコードの更新など、いくつかの小さなタスクが必要になります。
2. 移転する
2番目のR、 移転する、再ホストと似ています。どちらの方法でも、オンプレミスで実行されているアプリケーションをクラウドで実行されている VM インスタンスに移動する必要がありますが、重要な違いが 1 つあります。アプリケーションを再ホストするには、クラウド VM インスタンスを作成し、アプリケーションをそのインスタンスに移動する必要があります。一方、再配置では、既存の VM に大幅な変更を加えずに、オンプレミス環境からクラウドに移動します。
組織で VMware 仮想化ソフトウェアを実行しており、仮想マシンの 1 つをクラウドに移行する必要があるとします。面倒な手動の移行プロセスを実行するのではなく、クラウドで VMware を提供するプロバイダーを見つけて、VM をプロバイダーのクラウドに移行することができます。
このタイプの移行の最大の利点は、そのシンプルさです。もう 1 つの利点は、オンプレミスで使用していた仮想化プラットフォームのクラウド バージョンを使用しているため、IT スタッフの学習曲線がほとんどないことです。
3. プラットフォームの再構築
再ホスティングはリフト アンド シフトと呼ばれることもありますが、再プラットフォーム化はリフト アンド シェイプに近いものです。元は 改訂 Gartner の 5R モデルでは、次のように呼ばれることもあります。 持ち上げて、いじって、シフトする。
プラットフォーム再構築の背後にある考え方は、レガシー アプリケーションを移行する場合、クラウド プロバイダーはアプリケーションの作成時には存在しなかった多くの機能を提供する可能性があるということです。スケーラビリティや柔軟性など、クラウドが提供する機能を最大限に活用できるように、移行プロセスの一環としてアプリケーションを強化することは理にかなっています。
アプリケーションの再プラットフォーム化にはコストと時間がかかる傾向がありますが、場合によってはその労力が正当化されることもあります。これは、収益を増やしたり、アプリケーションを今後何年も使い続けられるようにするために、中核となる基幹業務アプリケーションを更新する場合に特に当てはまります。
留意すべき点の 1 つは、すべてのアプリケーションを再プラットフォーム化できるわけではないということです。プラットフォームの再構築は主に、オープンソース アプリケーションまたは社内で開発されたアプリケーションのオプションです。商用ソフトウェア ベンダーは通常、プラットフォーム変更の絶対条件であるソース コードを提供しません。
4. リファクタリング
4R目は、 リファクタリングは、クラウドが提供するすべてのものを活用するためにアプリケーションを変更する必要があるという点で再プラットフォーム化に似ていますが、重要な違いがあります。最も注目すべき点は、アプリケーションを再プラットフォーム化しても、そのアーキテクチャが保持され、ほぼ同じように動作し続けることです。これに対して、リファクタリングとは、アプリケーションに根本的なアーキテクチャ上の変更を加えることを意味します。たとえば、アプリケーションをマイクロサービスのコレクションに分割できます。
リファクタリングはおそらく、移行タイプの中で最も困難ですが、アプリケーションを将来にわたって保証する方法として価値がある場合があります。プラットフォームの再構築と同様、リファクタリングするにはアプリケーションのソース コードにアクセスする必要があります。
5. 再購入
５Ｒ目は、 買い戻す、いくつかの意味があります。 1 つは、オンプレミス アプリケーションを、同じことを行う競合するクラウドネイティブ アプリケーションに置き換えることを意味する場合があります。また、オンプレミス アプリケーションを SaaS バージョンのアプリケーションに置き換えることを意味する場合もあります。
最後に、再購入とは、サーバーレス管理システムを優先してレガシー アーキテクチャ コンポーネントを段階的に廃止することを指します。たとえば、組織は SQL Server データベースをマネージド サービスに置き換え、クラウド プロバイダーがクラウドで SQL Server を実行する場合があります。このアプローチの利点は、単に SQL Server をクラウドベースの VM 上で実行することとは対照的に、データベースがマネージド サービスとして提供される場合、クラウド プロバイダーが関連するすべてのメンテナンスを処理することです。プロバイダーはサービスの実行を維持し、必要な冗長性を提供し、必要なパッチ管理を処理します。
6. 引退
すべてのワークロードをクラウドに移行することが常に意味があるとは限りません。一部のレガシー アプリケーションを廃止したほうがよい場合があります。
ワークロードがベンダーによってアクティブにサポートされなくなった場合、そのワークロードは廃止に適している可能性があります。このような場合、組織がまだ使用しているアプリケーションを廃止する前に、回避策があることを確認することが重要です。これは、同様の機能を提供する競合アプリケーションを採用するか、社内で開発することを意味する場合があります。
場合によっては、古いアプリケーションを廃止する前に、組織のビジネス プロセスに大幅な変更を加える必要がある場合があります。たとえば、アプリケーションがサポートされなくなり、適切な代替品のコストが高額であることが判明した場合は、代わりにビジネス プロセスを変更した方がよい場合があります。
7. 保持する
7R目、 保持、本質的には、アプリケーションを当面放置しておくことを意味します。
あなたの組織が、現在オンプレミスで実行されている特定のアプリケーションに依存していると仮定します。クラウドに移行するというプレッシャーがあるかもしれませんが、ベンダーは今年後半に SaaS バージョンを発表しました。クラウド バージョンを待つことができるのに、クラウド移行のコストと手間に耐えるのはおそらく意味がありません。
保持戦略は、アプリケーションの依存関係を考慮する必要がある場合にも役立ちます。たとえば、組織にクラウドに移行したい特定のアプリケーションがあるとします。計画段階で、オンプレミスで実行されている別のアプリケーションが、組織が移行したいアプリケーションに依存しており、動作を停止する可能性があることがわかりました。この状況では、依存するアプリケーションが移行または廃止されるまで、アプリケーションを現在の状態に維持する必要があります。
Brien Posey は、元 22 回の Microsoft MVP であり、民間宇宙飛行士候補者です。 30 年以上の IT 分野でのキャリアの中で、米国国防総省の主任ネットワーク エンジニアや米国最大手の保険会社のネットワーク管理者を務めてきました。
#クラウド移行の #つの #適切な方法を選択する方法