クラウドの合理化
クラウドの合理化は、クラウド内の各資産の移行または最新化を行う上で最適な方法を決定するために資産を評価するプロセスです。 合理化のプロセスの詳細については、「デジタル資産とは」を参照してください。
合理化のコンテキスト
この記事に記載されている "合理化の 5 R" は、クラウドの候補と見なされるすべてのワークロードの将来見込まれる状態を分類するための優れた方法です。 この分類プロセスは、環境の合理化を試みる前に、適切なコンテキストで適用してください。 そのコンテキストを用意するために、次の根拠のない説を見直してください。
通説:プロセスの早い段階で合理化に関する決定を下すことは容易である
最適な合理化を行うには、ワークロードと関連する資産 (アプリケーション、インフラストラクチャ、データ) の深い知識が必要です。 最も重要なのは、的確に合理化するための意思決定には時間がかかることです。 増分型の合理化プロセスを使用することをお勧めします。
通説:クラウドの導入はすべてのワークロードが合理化されるまで待つべきである
IT ポートフォリオ全体あるいは単にデータセンター 1 つを合理化する場合、事業価値の合理化が、数か月、場合によっては数年にもわたって遅れる可能性があります。 可能な場合は、完全な合理化を避けます。 代わりに、リリース計画の 10 のパワーのアプローチを使用して、クラウド導入の候補となる次の 10 個のワークロードに関する賢明な意思決定を行います。
通説:ビジネスの正当化はすべてのワークロードが合理化されるまで待つべきである
クラウド導入への取り組みに対するビジネスの正当化を図るには、ポートフォリオ レベルでいくつかの基本的な想定を行います。 革新に対応することが動機の場合は、再設計を想定します。 移行に対応する場合は、再ホストを想定します。 これらの想定によって、ビジネスの正当化プロセスを高速化できます。 各ワークロードの導入サイクルの評価フェーズ中に、前提が変更され、予算が調整されます。
ここで、次の合理化の 5 R を見直して、この長期プロセスをよく理解してください。 クラウド導入計画を策定するときに、ご自身の動機、ビジネス成果、および現状の環境に最も適合しているオプションを選択してください。 デジタル資産の合理化の目標は、すべてのワークロードを合理化することではなく、ベースラインを設定することです。
合理化の 5 R
次の合理化の 5 つの R は、合理化のための最も一般的なオプションについて説明しています。
再ホスト
リホストの取り組みは、"リフト アンド シフト" 移行とも呼ばれ、アーキテクチャ全体への変更を最小限に抑えて、現在の状態の資産を選択されたクラウド プロバイダーに移動します。
一般的な促進要因には、次のものがあります。
- 資本コストの削減。
- データセンターの領域の解放。
- クラウドの投資収益率の迅速な達成。
定量分析の要素は、次のとおりです。
- CPU、メモリ、ストレージを含む VM サイズ。
- 依存関係 (ネットワーク トラフィックなど)。
- 資産の互換性。
定性分析の要素には、次のとおりです。
- 変更の許容範囲。
- ビジネスの優先順位。
- 重要なビジネス イベント。
- プロセスの依存関係。
リファクター
サービスとしてのプラットフォーム (PaaS) オプションは、多くのアプリケーションに関連した運用コストを削減できます。 PaaS ベースのモデルに適合するように、アプリケーションを少しリファクタリングすることをお勧めします。
リファクターはまた、アプリケーションが新しいビジネス機会を実現できるようにコードをリファクタリングするアプリケーション開発プロセスも指します。
一般的な促進要因には、次のものが含まれます。
- より迅速で、より短い更新。
- コードの移植性。
- リソース、速度、コスト、マネージド操作に役立つクラウド効率の向上。
定量分析の要素は、次のとおりです。
- CPU、メモリ、ストレージなど、アプリケーション資産のサイズ。
- 依存関係 (ネットワーク トラフィックなど)。
- ページ ビュー、ページ上の時間、読み込み時間など、ユーザーのトラフィック。
- 言語、データ プラットフォーム、中間層サービスなどの開発プラットフォーム。
- CPU、メモリ、ストレージ、バージョンを含むデータベース。
定性分析の要素には、次のとおりです。
- 継続的なビジネス投資。
- 増え続けるオプションまたはタイムライン。
- ビジネス プロセスの依存関係。
再設計
一部のエージング アプリケーションには、クラウド プロバイダーと互換性がありません。 この非互換性は、アプリケーションのビルド時に行われたアーキテクチャ上の決定に起因します。 この場合は、変革の前に、そのアプリケーションの再設計が必要になることがあります。
別の場合として、クラウドと互換性はあるが、クラウド ネイティブではないアプリケーションは、クラウド ネイティブ アプリケーションになるようにソリューションを再設計することによって、コスト効率と運用効率を生み出す可能性があります。
一般的な促進要因には、次のものが含まれます。
- アプリケーションのスケールとアジリティ。
- 新しいクラウド機能のより容易な導入。
- テクノロジ スタックの混在。
定量分析の要素は、次のとおりです。
- CPU、メモリ、ストレージなど、アプリケーション資産のサイズ。
- 依存関係 (ネットワーク トラフィックなど)。
- ページ ビュー、ページ上の時間、読み込み時間など、ユーザーのトラフィック。
- 言語、データ プラットフォーム、中間層サービスなどの開発プラットフォーム。
- CPU、メモリ、ストレージ、バージョンを含むデータベース。
定性分析の要素には、次のとおりです。
- 事業投資の拡大。
- 運用コスト。
- 潜在的なフィードバック ループおよび DevOps 投資。
[再構築]
一部のシナリオでは、アプリケーションを引き継ぐために克服する必要のある差分が大きすぎて、それ以上の投資を正当化できない場合があります。 以前はビジネスのニーズを満たしていても、現在のビジネス プロセスではサポートされていないアプリケーションには特にこの問題が当てはまります。 この問題を解決するには、クラウド ネイティブなアプローチに整合させるための新しいコード ベースを作成します。
一般的な促進要因には、次のものがあります。
- イノベーションの促進。
- アプリケーションをより迅速に構築。
- 運用コストの削減。
定量分析の要素は、次のとおりです。
- CPU、メモリ、ストレージなど、アプリケーション資産のサイズ。
- 依存関係 (ネットワーク トラフィックなど)。
- ページ ビュー、ページ上の時間、読み込み時間など、ユーザーのトラフィック。
- 言語、データ プラットフォーム、中間層サービスなどの開発プラットフォーム。
- CPU、メモリ、ストレージ、バージョンを含むデータベース。
定性分析の要素には、次のとおりです。
- エンド ユーザー満足度の低下。
- 機能によって制限されるビジネス プロセス。
- 潜在的なコスト、エクスペリエンス、または収益増加。
Replace
ソリューションは、通常、現時点で使用可能な最高のテクノロジとアプローチを使用して実装されます。 ホストされるアプリケーションに必要なすべての機能が、SaaS (サービスとしてのソフトウェア) アプリケーションから得られる場合があります。 これらのシナリオでは、ワークロードを将来置き換えることをスケジュールし、変革の取り組みから削除することもできます。
一般的な促進要因には、次のものがあります。
- 業界のベスト プラクティスに関する標準化。
- ビジネス プロセス主導のアプローチの導入の促進。
- 競争力のある差別化または利点を生み出すアプリケーションへの開発投資の再割り当て。
定量分析の要素は、次のとおりです。
- 一般的な運用コストの削減。
- CPU、メモリ、ストレージを含む VM サイズ。
- 依存関係 (ネットワーク トラフィックなど)。
- 廃棄される資産。
- CPU、メモリ、ストレージ、バージョンを含むデータベース。
定性分析の要素には、次のとおりです。
- 現在のアーキテクチャと SaaS ソリューションの間のコスト メリット分析。
- ビジネス プロセス マップ。
- データ スキーマ。
- カスタムまたは自動化プロセス。
次のステップ
デジタル資産に対し、これらの合理化の 5 R を適用することで、各アプリケーションの将来の状態に関する合理化の決定がしやすくなります。