次の方法で共有


クラウドの合理化

クラウドの合理化は、資産を評価して、クラウド内の各資産を移行または最新化する最適な方法を決定するプロセスです。 合理化のプロセスの詳細については、「 デジタル資産とは」を参照してください。

合理化コンテキスト

この記事に記載されている 合理化の 5 R は、クラウド候補と見なされているワークロードの将来の潜在的な状態にラベルを付ける優れた方法です。 環境を合理化する前に、このラベル付けプロセスを正しいコンテキストに配置します。 そのコンテキストを提供するには、次の神話を確認します。

神話:プロセスの早い段階で合理化の決定を行うのは簡単です

適切な合理化には、ワークロードと関連する資産 (アプリケーション、インフラストラクチャ、データなど) に関する深い知識が必要です。 最も重要なのは、適切な合理化の決定には時間がかかることです。 増分合理化プロセスを使用することをお勧めします。

神話:クラウド導入は、すべてのワークロードが合理化されるのを待つ必要があります

IT ポートフォリオ全体または単一のデータセンターが合理化されると、ビジネス価値の実現が数か月または数年遅れる可能性があります。 可能な場合は、完全な合理化を避けてください。 代わりに、 Power of 10 アプローチを使用して計画をリリース し、クラウド導入のために予定されている次の 10 個のワークロードについて賢明な意思決定を行います。

通説:ビジネス上の正当な理由は、すべてのワークロードが合理化されるのを待つ必要がある

クラウド導入作業のビジネス上の正当な理由を開発するには、ポートフォリオ レベルでいくつかの基本的な仮定を行います。 動機がイノベーションに沿っている場合は、再設計を想定します。 移行に合わせて調整されている場合は、再ホストを想定します。 これらの前提条件により、業務上の正当な理由のプロセスが促進される可能性があります。 各ワークロードの導入サイクルの評価フェーズでは、前提条件がチャレンジされ、予算が調整されます。

次に、次の 5 つの合理化 R を確認して、長期的なプロセスについて理解します。 クラウド導入計画を策定する際に、動機、ビジネス成果、現在の状態環境に最適なオプションを選択します。 デジタル資産の合理化の目標は、すべてのワークロードを合理化するのではなく、ベースラインを設定することです。

合理化の 5 R

合理化の次の 5 Rs では、合理化の最も一般的なオプションについて説明します。

リホスト

リフト アンド シフト移行とも呼ばれるリホスト作業では、現在の状態資産が選択したクラウド プロバイダーに移動され、アーキテクチャ全体の変更は最小限に抑えられます。

一般的な促進要因には、次のものがあります。

  • 資本コストの削減。
  • データセンターのスペースを拡張する。
  • クラウドの投資収益率の迅速な達成。

定量分析の要因は次のとおりです。

  • CPU、メモリ、ストレージを含む VM サイズ。
  • ネットワーク トラフィックなどの依存関係。
  • 資産の互換性。

定性分析の要因は次のとおりです。

  • 変更の許容範囲。
  • ビジネスの優先順位。
  • 重要なビジネス イベント。
  • プロセスの依存関係。

リファクター

サービスとしてのプラットフォーム (PaaS) オプションを使用すると、多くのアプリケーションに関連する運用コストを削減できます。 PaaS ベースのモデルに合わせてアプリケーションを少しリファクタリングすることをお勧めします。

リファクタリング とは、アプリケーションが新しいビジネスチャンスを実現できるようにコードをリファクタリングするアプリケーション開発プロセスも指します。

一般的なドライバーには、次のようなものがあります。

  • 更新プログラムの高速化と短縮。
  • コードの移植性。
  • リソース、速度、コスト、管理された運用に役立つクラウド効率の向上。

定量分析の要因は次のとおりです。

  • CPU、メモリ、ストレージなどのアプリケーション資産のサイズ。
  • ネットワーク トラフィックなどの依存関係。
  • ページ ビュー、ページ上の時間、読み込み時間などのユーザー トラフィック。
  • 言語、データ プラットフォーム、中間層サービスなどの開発プラットフォーム。
  • CPU、メモリ、ストレージ、バージョンを含むデータベース。

定性分析の要因は次のとおりです。

  • 継続的な事業投資。
  • 増え続けるオプションまたはタイムライン。
  • ビジネス プロセスの依存関係。

再設計

一部の古いアプリケーションは、クラウド プロバイダーと互換性がありません。 この非互換性は、アプリケーションのビルド時に行われたアーキテクチャ上の決定が原因です。 このような場合は、変換の前にアプリケーションを再設計する必要があります。

また、クラウドと互換性はありますが、クラウドネイティブではないアプリケーションは、ソリューションをクラウドネイティブ アプリケーションに再設計することで、コスト効率と運用効率を生み出す可能性があります。

一般的なドライバーには、次のようなものがあります。

  • アプリケーションのスケールと機敏性。
  • 新しいクラウド機能の導入が容易になります。
  • テクノロジ スタックの組み合わせ。

定量分析の要因は次のとおりです。

  • CPU、メモリ、ストレージなどのアプリケーション資産のサイズ。
  • ネットワーク トラフィックなどの依存関係。
  • ページ ビュー、ページ上の時間、読み込み時間などのユーザー トラフィック。
  • 言語、データ プラットフォーム、中間層サービスなどの開発プラットフォーム。
  • CPU、メモリ、ストレージ、バージョンを含むデータベース。

定性分析の要因は次のとおりです。

  • ビジネス投資を拡大するため。
  • 運用コスト。
  • 潜在的なフィードバック ループと DevOps への投資。

建て直す

一部のシナリオでは、アプリケーションを進めるために克服する必要がある差分が大きすぎて、さらなる投資を正当化できない場合があります。 この問題は、以前はビジネスのニーズを満たしていたが、現在のビジネス プロセスではサポートされていないアプリケーションに特に当てはまります。 この問題を解決するには、 クラウドネイティブ のアプローチに合わせて新しいコード ベースを作成します。

一般的な要因としては、次のようなものがあります。

  • イノベーションの促進。
  • アプリケーションをより迅速に構築。
  • 運用コストの削減。

定量分析の要因は次のとおりです。

  • CPU、メモリ、ストレージなどのアプリケーション資産のサイズ。
  • ネットワーク トラフィックなどの依存関係。
  • ページ ビュー、ページ上の時間、読み込み時間などのユーザー トラフィック。
  • 言語、データ プラットフォーム、中間層サービスなどの開発プラットフォーム。
  • CPU、メモリ、ストレージ、バージョンを含むデータベース。

定性分析の要因は次のとおりです。

  • エンド ユーザーの満足度の低下。
  • 機能によって制限されるビジネス プロセス。
  • 潜在的なコスト、経験、または収益の向上。

置換

通常、ソリューションは、その時点で利用可能な最適なテクノロジとアプローチを使用して実装されます。 サービスとしてのソフトウェア (SaaS) アプリケーションは、ホストされているアプリケーションに必要なすべての機能を提供できる場合があります。 これらのシナリオでは、ワークロードを将来の置き換えにスケジュールすることができ、変換作業から削除されます。

一般的な動機には次のようなものがあります。

  • 業界のベスト プラクティスに関する標準化。
  • ビジネス プロセス主導のアプローチの導入を加速します。
  • 競争力のある差別化または利点を生み出すアプリケーションへの開発投資の再割り当て。

定量分析の要因は次のとおりです。

  • 一般的な運用コストの削減。
  • CPU、メモリ、ストレージを含む VM サイズ。
  • ネットワーク トラフィックなどの依存関係。
  • 廃止される資産。
  • CPU、メモリ、ストレージ、バージョンを含むデータベース。

定性分析の要因は次のとおりです。

  • 現在のアーキテクチャと SaaS ソリューションのコストメリット分析。
  • ビジネス プロセス マップ。
  • データ スキーマ。
  • カスタムまたは自動化されたプロセス。

次のステップ

これらの 5 つの合理化 Rs をデジタル資産に適用して、各アプリケーションの将来の状態に関する合理化の決定を行うことができます。