クラウド導入の取り組み
クラウド導入の取り組みも同様の軌道に従う傾向があります。 バリエーションは存在しますが、それでも他の組織がクラウドを導入する方法を確認すると役立ちます。 最初に取り組むべきワークロードとその対処方法を把握することで、クラウド導入の取り組みを効率化できます。
適切なクラウド ソリューションを採用する際の重要な考慮事項は、制御と生産性のバランスです。 サービスとしてのインフラストラクチャ (IaaS) ソリューションを使用すると、最も厳密に制御できますが、保守に多くの時間が必要になります。 サービスとしてのプラットフォーム (PaaS) およびサービスとしてのソフトウェア (SaaS) ソリューションは、管理責任を Azure に移転し、チームが生産性の向上に集中できるようにします。 制御と生産性のバランスは組織ごとに異なり、時間の経過とともに優先順位が変わると変化します。
最初のクラウド導入では、一般的な組織はアプリケーションの 35% を廃止し、ポートフォリオの 15% を置き換え、50% は必要な変更のみ移行します (リプラットフォームまたはリホスト)。
廃止 (35%)
組織が必要としないワークロードを廃止します。 投資継続に見合わないアプリケーションや環境を見つけるために、検出を実行し評価する必要があります。 コストと時間の効率化が廃止の目標です。 クラウドに移行する前にポートフォリオを縮小すると、チームは最も重要な資産に集中できます。
置換 (10%)
ほとんどの組織は、アプリケーションの約 10% をサービスとしてのソフトウェア (SaaS) およびローコード ソリューションに置き換えます。 より生産性の高いソリューションを採用することで、より簡単に目標を達成できます。
表 1 - ワークロードを SaaS およびローコード ソリューションに置き換える例
| ソース | ターゲット |
|---|---|
| 業務 (LOB) アプリケーションの カスタムライン |
Power Apps |
| DevOps ツール | GitHub |
| 関係 管理 |
Dynamics 365 |
| 企業 業種 |
サードパーティー SaaS |
リアーキテクトまたはリビルド (5%)
必須のビジネスアプリケーションを SaaS またはロー コードのソリューションに置き換えることができない場合、アプリケーションの再設計を検討します。 再設計や再構築は複雑ですが、クラウド テクノロジを最大限に活用するために不可欠です。 主な目標は、クラウド用にこれらのアプリケーションを調整することです。 このアプローチには、いくつかの重要な局面があります。
- スケーラビリティ: さまざまな需要レベルを効率的に処理するようにアプリケーションを調整します。
- 信頼性: 失敗なく一貫して動作するようアプリケーションの機能を向上させます。
- セキュリティ: 高度なセキュリティ対策を統合して、クラウド内のデータとオペレーションを保護します。
この段階で、生成 AI などの高度なテクノロジを統合することもできます。 統合ソリューションにより、アプリケーションの機能を大幅に強化できます。 次に AI テクノロジの例を示します。
- 予測分析: AI を使用して顧客ニーズを予測します。
- プロセス自動化: AI を使用してビジネス プロセスを自動化します。
リアーキテクトやリビルドにより、クラウドネイティブ機能と AI 主導の進歩の全範囲を活用できます。
再ホストまたは再プラットフォーム (50%)
一般的な企業は、約半分の既存のワークロードを移行します。 これらのワークロード内には、通常、3 つのレベルの難易度があります。 約 35% は容易に移動できます。 次の 10% は、より複雑またはより重要であるためより困難です。最後の 5% のみは、実行のための追加の計画が必要です。
多くの移行方法があります。 リホスト ("リフトアンドシフト") とリプラットフォーム ("最新化") が、最も一般的であり、クラウド導入に推奨されるアプローチです。 しかし、ニーズを満たす方法を決定するのは難しい場合があるため、適切なアプローチを決定するためのガイダンスを用意しています。 詳細については、「移行しますか、それともモダン化しますか?」を参照してください。
最初に移行する (35%)
最初にワークロードを移動する場合は、簡単に成功できる方法を選択することをお勧めします。 この戦略により、より複雑なワークロードに取り組む前に、より簡単なアプリケーションで導入計画を評価できます。 作業するときは、成功をドキュメント化し、必要に応じて戦略を改訂してください。 これらの分析情報を、より複雑な移行に適用します。 最初の移動に含めることができるワークロードの例として、基本的な Web アプリと高度なポータルの 2 つがあります。
基本的な Web アプリ: 基本的な Web アプリケーションをリホストし、基本的な Web アプリの移動が完了するまで、より複雑なワークロードの移動を待機することをお勧めします。 Azure App Serviceは、ほとんどのアプリケーションをホストできる柔軟なアプリケーション プラットフォームです。 基本的な Web アプリケーションには、このソリューションをお勧めします。 詳細については、Azure App Serviceに関するページを参照してください。
高度なポータル: 生産性を向上させるために、ポータルを Power Apps ポータルに移行する必要があります。
次に移行する (10%)
より困難なワークロードやより重要なワークロードに取り組むために、最初の移動から学んだ教訓を適用する必要があります。 ワークロードの種類を理解するための例がいくつかあります。
ビジネスへの影響大: 収益を促進するワークロード、またはミッション クリティカルなワークロード。
高入出力 (I/O) オンライン トランザクション処理 (OLTP) システム: これらのワークロードはビジネス トランザクションを記録し、高い処理要件を持っています。
規制対象情報: これらのワークロードは、HIPAA、PCI DSS などの法律および業界標準に従う必要があります。 Azure Policy を使用して、これらの標準への準拠を確保することをお勧めします。 詳細については、Azure Policy に関するページをご覧ください。
移行が困難またはコストがかかる (5%)
最も困難でコストの高いワークロードを最後に移行します。 次のようなシステムでは、効率的に移行するために追加の考慮が必要になる場合があります。
高価値資産 (HVA): このワークロードの中断または破損により、すべての業務が中断されます。
公開キー基盤 (PKI) システム: x509 デジタル証明書、ネットワーク暗号化、認証を管理するワークロード。
従来のソース管理: GitHub に簡単に置き換えることができないソース管理システム。
最新化できないもの: 最新化できない従来のテクノロジまたは独自のテクノロジ。
アーキテクチャの大幅な変更: アーキテクチャの完全な再設計を必要とするレガシ アーキテクチャ。 CAF の最新化アプローチではなく、Microsoft Azure Well-Architected フレームワーク を使用します。
その他のリソース
- Azure Migrate で利用できるツールを使用して、体験を単純化します。
- セルフガイド付きデジタル サポートと、エキスパートガイド付きデプロイのために、移行およびモダン化プログラムに参加します。
- FastTrack for Azure を使用して、Azure エンジニアからカスタマイズされたガイダンスを取得します。