お客様のストーリー
入門モジュールで、Tailwind Traders のいくつかの目標を紹介しました。 Tailwind Traders のクラウド戦略チームは、財政および技術上の考慮事項に対応する役員レベルの戦略を策定しました。
クラウド導入計画は、その戦略的プログラムに寄与するさまざまなプロジェクトを管理するために用意されています。 中央の運用およびインフラストラクチャ チームは、短期のコンプライアンスと運用のニーズを満たす Azure ランディング ゾーンをデプロイしました。
このモジュールと最も関連性が高いのは、リースしている 2 つのデータ センターをリース期限が終了する前に移行する作業です。 これらのデータ センターでは、店舗内および eコマースの運用をサポートする運用ワークロードの広範なポートフォリオがホストされています。 第 2 データセンターでは、Dev/Test 環境や、小売イノベーション チームからのその他の運用前イノベーションもホストされています。
Tailwind のストーリーを再開します。移行チームはちょうど、クラウドへのワークロードの移行を開始する準備をしています。
Tailwind Traders の移行計画
計画モジュールでは、Azure Migrate を使用して同社のデジタル資産を合理化し、Azure DevOps での移行をガイドするバックログを作成しました。 移行チームは、既存のデータ センターをクラウドに移行する作業をいつでも開始できるようになりました。 残りの 12 か月で、チームはワークロードのウェーブを段階的に移行する予定です。 この移行のスコープとタイムラインを考慮して、チームは次の移行ファクトリ アプローチを選択しました。
図 1: 移行プロセスの各スプリントで必要となる一般的なタスク。
1 つの小規模なチームが、Azure Migrate を使用して、2 週間のスプリントごとにワークロードの 1 つのウェーブを移行することに集中します。
2 番目の小規模なアーキテクト チームは、移行チームより 1 から 2 ウェーブ先に作業を行います。 移行する各ワークロードの評価と設計に焦点を当てています。
このチームは、現状のアプリケーションと望ましい合理化目標の間の互換性問題を検出して修正します。 また、最初の合理化作業からサイズを評価して、適切なリソース割り当ても確保します。
3 番目の Azure エキスパートの小規模なチームは、移行チームより 1 から 2 ウェーブ遅れて作業を行います。 移行されたワークロードのテスト、微調整、アーキテクチャに重点を置いています。
このチームは、移行されたワークロードに運用トラフィックをリリースする前に、ビジネス ユーザーと共に移行されたワークロードをテストして、パフォーマンスを検証します。 このチームは、運用リリース前にアーキテクチャの調整が必要なワークロードに対して、Azure Well-Architected フレームワークと Azure Well-Architected レビューの評価も使います。
重要
ワークロードの量と、この最初の移行を完了するための限られた期間のため、Tailwind Traders にはこの移行ファクトリ アプローチが不可欠です。 通常、組織は、単一の自己組織化移行チーム内だけで、3 つの機能すべてを実施できます。 このチームは、1 つのスプリントで各ワークロード ウェーブの評価、移行、リリースを完了できます。
テクノロジ プラットフォームの多様性への準備
ほとんどのお客様と同様に、Tailwind Traders はさまざまなテクノロジ プラットフォームをサポートする必要があります。 同社の主な懸念は、Linux と OSS のデータ プラットフォームで実行されているオープンソース ソリューションのコレクションが大規模であり、拡大し続けていることです。 また、Azure Virtual Desktop ソリューションをクラウドでホストする方法も評価しています。 ある時点で、SAP HANA ソリューションをクラウドに移行することも必要になります。
チームはこの移行プロジェクトの準備を行うにあたって、Windows と SQL Server の資産の移行と最新化に必要なスキルを確保する必要があります。 また、同じプロセス内の他のテクノロジ プラットフォームにも対応できる必要があります。
このモジュールの残りのユニットでは、さまざまなチーム構造と複数のテクノロジ プラットフォームにおいて成功するためのプロセス、ツール、アプローチを見ていきます。