アプリケーション移行の 5 つの R は今でも適用されますか?

[51CTO.com クイック翻訳] クラウド コンピューティングの初期の頃、ガートナーはアプリケーション移行のいわゆる 5 つの R を定義しました。多くのユーザーは、これらの 5 つの方法は興味深いが曖昧であると感じており、5R が今でも適用できるかどうか疑問視する人もいます。

現代のクラウドの観点から 5 つの R について考え、開発者がアプリケーション移行プロセスを再考する必要がある理由について説明します。

[[254934]]

1. 再ホスト

再ホスティングは移行とも呼ばれ、企業がアプリケーションをローカルの物理システムからクラウド仮想マシンに移行することです。このアプローチでは、クラウドに必要なデプロイメント構成パラメータのいくつかの調整を除いて、アプリケーションに大きな変更は加えられません。

アプリケーションの最新化ではなくサーバーの統合に重点が置かれている場合でも、再ホスティングは依然として役立ちます。しかし今日では、多くの企業は、スケーラビリティと弾力性の面でさらなるメリットを得るために、VM よりもコンテナに注目しています。コンテナを使用すると、企業はデプロイメントと接続のパターンを標準化できるため、開発者はその構造に適合しないアプリケーションを変更する必要があります。

2. リファクタリング

リファクタリングとは、企業がアプリケーションを仮想マシンではなく PaaS 環境に移行することを指します。 2011 年にガートナーが 5R を発表した当時、リファクタリングと再ホスティングはそれぞれ PaaS への移行と IaaS への移行を意味していましたが、今日では状況はより複雑になっています。 PaaS は現在、非常に広い意味を持ち、クラウド プロバイダーによって提供される管理対象リソースやネイティブ Web サービスを指すことがよくあります。

3. 修正する

変更とは、企業がアプリケーションをクラウドベースのインフラストラクチャに適合させるプロセスです。現在、クラウド インフラストラクチャには、ホスティングだけでなく、多数のクラウド ネイティブ サービスも含まれています。たとえば、開発者は古いデータベースをクラウド バージョンに置き換えて、アプリケーションをクラウドでより効率的に実行できるようになります。

4. 再構築

再構築中に、開発者はクラウド専用にアプリケーションを書き直しました。企業はこのオプションを、アプリケーション全体のフォークリフト交換と見なしており、混乱を招くことがよくあります。しかし、現在、再構築には、クラウドネイティブ Web サービスを使用するようにアプリケーションを変更するか (リファクタリングとリビジョンを組み合わせたプロセス)、アプリケーションを新しいクラウド フロントエンド コンポーネントと従来のトランザクション バックエンド コンポーネントに分解する必要があります。

多くの企業は、データセンターで引き続き実行されるレガシー アプリケーションに、クラウドでホストされるブラウザーとモバイル アプリのサポートを追加しています。この場合、アプリケーションのクラウドホスト型フロントエンドは完全に新しくなりますが、従来のバックエンドはまったく変更されないか、大幅に変更されることはありません。したがって、ほとんどのユーザーにとって、再構築はアプリケーション移行プロセスの一部ではありません。

5. 置き換える

***最初の R は置き換えを意味し、古いアプリケーションをホストされた SaaS バージョンに完全に置き換えることを意味します。ただし、通常、水平型またはより一般的なビジネス アプリケーションに使用できるのは SaaS オプションのみです。コアビジネスアプリケーションが SaaS として提供されることはほとんどなく、多くの企業ではそのようなアプリケーションを自社のデータセンターの外で実行することはありません。したがって、企業は市場にある既存の SaaS オプションを確実に評価する必要がありますが、今日の SaaS アプリケーションは依然として、ユーザーが独自のソフトウェアと統合する必要があるクラウド プロバイダーの Web サービスのサードパーティ拡張機能に似ています。

アプリケーション移行に対する考え方を変える

上記のいくつかの要因により、5 つの R がアプリケーション移行プロセスを常に正しくガイドするとは限りません。クラウド テクノロジーは驚異的なスピードで進化しているため、これは驚くべきことではありません。ここで、元の 5 つの R を、Rethink と Rearchitect という 2 つの新しい R に置き換える必要があります。

今日の企業は、アプリケーションをクラウドに移行するのではなく、クラウド向けのアプリケーション設計を再考しています。これにより、コスト効率よく実行できないアプリケーションやコンプライアンス要件を満たすアプリケーションのために従来のデータセンター インフラストラクチャへの投資を保護しながら、クラウド ネイティブの機能と利点を最大限に活用できるようになります。このプロセスの一環として、開発者はアプリケーションをより小さなコンポーネントに分割することがよくあります。

アプリケーション設計を再考した後、開発者の次のステップは、クラウドで実行されるアプリケーション コンポーネントのアーキテクチャを再設計することです。利用可能な Web サービスと SaaS ツールをインベントリし、アプリケーションの各クラウド互換コンポーネントを割り当てて変更し、最適なツールを使用します。

従来、トランザクション処理とユーザー インターフェイス コンポーネントが明確に分離されていたアプリケーションは、通常、再考され、再設計され、ユーザー向けのコンポーネントがクラウドで実行されます。クラウドに配置する必要があるのは、非常に変動の大きいリソースを必要とするアプリケーション、または一部のクラウド サービスによって品質とパフォーマンスを向上でき、独自のユーザー インターフェイス コンポーネントを持たないアプリケーションのみです。

原題: クラウド向けアプリ移行戦略を再考する時が来た、著者: Tom Nolle

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。