ランディング ゾーンのリファクター
ランディング ゾーンは、コードを使用して事前プロビジョニングされたワークロードをホストするための環境です。 ランディング ゾーンのインフラストラクチャはコードで定義されるため、他のどのコードベースにも同様にリファクターできます。 リファクタリングとは、ソース コードを変更または再構築して、目的や中核機能を変更することなく、そのコードの出力を最適化するプロセスです。
準備手法ではリファクタリングの概念を利用して、移行を促進し、一般的な阻害要因を取り除きます。 準備の概要の手順では、ホストする機能に最適な定義済みのランディング ゾーン テンプレートを使用して開始するプロセスについて説明しています。 その後、ソース コードに対するリファクターまたは追加を行って、強化されるセキュリティ、運用、またはガバナンスを通してその機能を提供するランディング ゾーンの機能を拡張します。 次の図に、リファクタリングの概念を示します。
図 1: ランディング ゾーンのリファクタリング。
一般的な阻害要因
お客様がクラウドを採用する場合、導入とクラウドに関連するビジネス上の成果に対して、ランディング ゾーンの考慮事項が最も一般的な単一の阻害要因となります。 お客様の考えは、次の 2 つの阻害要因のいずれかに傾く傾向があります。 多くの場合、さまざまなチームの考えが、これら 2 つの阻害要因のいずれかに傾くため、導入を困難にする文化的デッドロックが発生します。
どちらの主要な阻害要因も、1 つの考えに根ざしています。クラウド環境と既存のデータセンターは、運用、ガバナンス、およびセキュリティに関して、機能パリティであるか、それに近い必要がある、という考えです。 これは、賢明な長期的目標です。 しかし、その目標を達成するタイミングと、ビジネス上の成果を提供するために必要な速度との間の微妙なバランスから、問題が生じてきます。
阻害要因:行動のタイミングが早すぎる
現在のデータセンターにおいては、現在の状態のセキュリティ ガバナンスと運用に到達するまで、何年もの多大な労力が費やされています。 その環境に固有の制約を満たすためにも、観察、学習、およびカスタマイズが必要とされました。 それらと同じ手順や構成を再現するのには時間がかかります。 また、完全な機能パリティに達すると、クラウドでのパフォーマンスが下回る環境となる可能性もあります。 このパリティ アプローチは、一般に、クラウド環境での計画外の大幅な支出超過にもつながります。 初期段階の目標として、将来の状態の環境に、現在の状態の要件を適用しようとしないでください。 そのようなアプローチが有益であることは、めったにありません。
図 2: 行動のタイミングが早すぎるのは、一般的な阻害要因の 1 つ。
上の図では、お客様は、クラウドで実行されるワークロードの数を 100 にする目標を掲げています。 これを実現するために、お客様は最初のワークロードをデプロイした後、最初の 10 個くらいのワークロードを、そのいずれかを運用環境にリリースする準備が整う前にデプロイすることも少なくありません。 最終的には、導入計画の目標に到達し、クラウドに堅牢なポートフォリオが用意されます。 しかし、図中の赤い X は、お客様がよく行き詰まる場所を示しています。 全体的な整合を待っていると、最初のワークロード導入が、週、月、場合によっては年単位で遅れる可能性があります。
阻害要因:行動のタイミングが遅すぎる
一方で、行動のタイミングが遅すぎると、クラウド導入作業を成功させることに関して、非常に大きな長期的影響が及ぶ可能性があります。 チームが、機能パリティに到達するのを待ってから導入作業が完了したとする場合は、不必要な障害が発生して、作業を計画どおり進め続けるためにいくつかの強化が必要になります。
図 3: 行動のタイミングが遅すぎるのは、一般的な阻害要因の 1 つ。
この図では、行動のタイミングが早すぎる場合と同様に、ランディング ゾーン全体にわたってエンタープライズ対応に到達するまで、お客様が待つ時間が長くなりすぎます。 待つ時間が長すぎると、お客様には、その環境で実行可能なリファクタリングと拡張の量について制約が生じることになります。 それらの制約によって、継続的な成功を促進する能力が限定されます。
バランスを取る
これらの一般的な阻害要因を回避するため、適切に構造化されたクラウド導入計画に基づく反復的なアプローチをお勧めします。このアプローチでは、学習の機会が最大限になり、ビジネス上の成功までの時間が最小限になります。 このアプローチには、リファクタリングと、並行しての作業が不可欠です。
警告
クラウドで 1,000 を超える資産 (アプリケーション、インフラストラクチャ、またはデータ資産) をホストするという中期目標 (24 か月以内) を設けている導入チームが、リファクタリングのアプローチを使用して成功する可能性はほとんどありません。 スキルの獲得に至る自然なアプローチを実現するには、学習曲線が急すぎてタイムラインに余裕がなさすぎます。 必要なカスタマイズの量がより少ない、より完全な開始点を選択すれば、目標を達成するための優れたパスとなります。 実装のパートナーが、より優れたアプローチを手引きできる可能性があります。
この記事の残りの部分では、リスクを最小限に抑えながらリファクタリング アプローチを強化できる、いくつかの重要な制約に焦点を当てます。
理論
ランディング ゾーンのリファクタリングという概念は単純ですが、実行するには適切なガードレールが必要です。 上の図に示した概念は、次のような基本的な流れの概要です。
- 最初のランディング ゾーンを構築する準備ができたら、テンプレートによって定義される最初のランディング ゾーンから開始します。
- そのランディング ゾーンがデプロイされたら、目次の「
Enhance」セクションの下にある記事のガイダンスを使用して、最初のランディング ゾーンに対するリファクタリングと追加を行います。 - セキュリティ チーム、運用チーム、およびガバナンス チームの拡張された要件を満たすエンタープライズ対応環境ができるまで、レビューと追加のプロセスを繰り返します。
開発アプローチ
リファクタリング ベースのアプローチの利点は、開発のために並列の繰り返しパスを作成できることです。 下の図は、クラウド導入とクラウド プラットフォームから成る、2 つの並列繰り返しパスの例を示しています。 どちらも独自のペースで進行するので、いずれかのチームの日々の取り組みに対する阻害要因となるリスクが最小限になります。 導入計画とリファクタリング ガードレールに関する整合により、マイルストーンについて合意が得られ、将来の状態の依存関係が明確になります。
図 4:ランディング ゾーンの並列の繰り返し。
上記の繰り返しパスの例では、クラウド導入チームが、100 のワークロードのポートフォリオをクラウドに移行しようとしています。 並行して、クラウド プラットフォーム チームは、それらのワークロードのために環境が確実に準備されるように、クラウド導入計画より先行することに重点を置いています。
この例では、計画された繰り返しは以下のように実行されます。
- クラウド プラットフォーム チームは、最初のランディング ゾーンをデプロイすることで開発作業を開始します。 そのランディング ゾーンで、クラウド導入チームは最初のワークロードをデプロイし、テストを開始することができます。
- クラウド導入チームの次の 10 個のワークロードのデプロイを準備するため、クラウド プラットフォーム チームは先行して作業し、接続される環境をリファクターして追加します。そこで、クラウドを境界ネットワークとして扱います。
- 導入チームが最初の運用ワークロードをリリースする前に、セキュリティ チームがセキュリティ レビューを行う必要があります。 導入チームが最初の 10 個のワークロードをデプロイする間に、プラットフォーム チームは先行して、セキュリティ要件の定義と実装を行います。
- 最初のワークロードが運用環境にリリースされるまでに、両方のチームに、より長期的な共有サービス モデルを準備するために十分な学習機会を設ける必要があります。 コア サービスのアーキテクチャを一元化すると、ガバナンスと運用チームを整合させる助けとなります。 コア サービスの一元化は、導入チームが、以後のいくつかの運用ワークロードのスケーリングとリリースを準備するのに役立ちます。
- チームが 100 ワークロードを移行する目標に近づくにつれて、チームは自然と、優れたコラボレーション モデルとチーム構造のクラウド センターに向けた移行をより重視し始めることになります。
エンタープライズ対応環境の構成には時間がかかります。 このアプローチでは、その要件はなくなりません。 そうではなく、このアプローチは、早期の阻害要因を取り除き、プラットフォーム チームと導入チームが一緒に学習する機会を作り出すことが目的となっています。
ランディング ゾーンのリファクタリング ガードレール
すべての初期ランディング ゾーン テンプレートに制限事項があります。 リファクタリング時のガードレールやポリシーに、それらの制限を反映させる必要があります。 ランディング ゾーンのリファクタリング プロセスを開始する前に、初期テンプレートの制限事項と比較したうえで、クラウド導入計画の長期的な要件と候補ワークロードの分類について理解しておくことが重要です。
リファクタリング ガードレールを確立する例として、前の例の開発アプローチと、CAF 移行ランディング ゾーンのブループリントを比較してみましょう。
- CAF 移行ランディング ゾーンのブループリントの前提条件に従えば、この最初のランディング ゾーンは、機密データやミッション クリティカルなワークロード向けに設計されていません。 それらの機能は、リファクタリングを通して追加する必要があります。
- この例では、100 ワークロードのポートフォリオのために、ミッション クリティカルかつ機密であるデータのホスティング機能が必要であると想定します。
これらの競合する 2 つの要件のバランスを取るために、導入チームとプラットフォーム チームは、以下の条件に同意し、それらに基づいて運用を行います。
- クラウド導入チームは、機密データにアクセスできず、ミッション クリティカルとは見なされない運用ワークロードを優先させます。
- 運用リリースより前に、セキュリティと運用のチームが、以前のポリシーへの準拠状況を検証します。
- クラウド プラットフォーム チームは、セキュリティ チームおよびガバナンス チームと協力して、セキュリティ ベースラインを実装します。 セキュリティ チームが実装を承認すると、導入チームが、一部の機密データにアクセスできるワークロードを移行することが許可されます。
- クラウド プラットフォーム チームは、運用チームと協力して管理ベースラインを実装します。 運用チームが実装を承認すると、導入チームが、より高いレベルの重要度を持つワークロードを移行することが許可されます。
この例では、上記の一連の合意済み条件によって、導入チームが移行作業を開始できるようになります。 これは、プラットフォーム チームが長期的なエンタープライズ対応環境に向けて構築する際に、他のチームとの対話を形作ることにも役立ちます。
リファクタリング時に長期的な要件に対応する
ランディング ゾーンの強化に関する準備手法のセクションは、長期的な要件に向けた移行の助けとなります。 クラウド導入チームが導入計画に基づいて作業を進めるときに、さまざまなチームの発展する要件を満たすように決定を下し、リファクターするのに役立つガイダンスについて、「ランディング ゾーンを拡張する」をご覧ください。
図 5: ランディング ゾーンの並列の繰り返しを支援するより深い手法。
「ランディング ゾーンを拡張する」の各サブセクションは、上の図で説明している追加のいずれかに対応します。 それらの基本的拡張を超える、このフレームワークのより深い手法 (ガバナンスや管理など) は、基本的なランディング ゾーンの変更を超えて長期的な規範を実装するのに役立ちます。
次のステップ
リファクタリング プロセスを始めるには、Azure ランディング ゾーンの使用を始めます。