データ アプリケーション参照パターン
データ アプリケーションを Data Landing Zone にオンボードすると、チームには専用のリソース グループ、サブネット、共有リソースへのアクセス権が付与されます。 この時点から、環境の所有権はデータ アプリケーション チームに引き渡されます。 これらのチームは、エンド ツー エンドの実装とコスト所有権の観点から責任を負う必要があります。
開始プロセスを簡略化し、特定のユース ケースの環境を作成するためのリード タイムを短縮するために、組織は内部参照パターンを提供できます。 これらの参照実装は、コードとしてのインフラストラクチャ (IaC) 定義で構成され、バッチ データ処理、ストリーミング データ処理、データ サイエンスなど、特定のユース ケース用の一連のサービスを正常に作成し、成功への道筋を示します。 これらのパターンには、データ ソリューションを実装するときにベースラインとして使用できる汎用アプリケーション コードも含まれている可能性があります。 データ アプリケーションの参照パターンは、組織によって異なる場合があり、使用されているツールや、Data Landing Zones 全体で頻繁に使用されるデータ実装パターンに大きく依存します。
その他の自動化を使用して、潜在的な摩擦点をさらに減らし、データ アプリケーション チームのパターンの初期デプロイも自動化できます。 詳細については、クラウド規模の分析
最終的には、ソリューションの全体的なコードベースを所有する必要があるため、これらの参照実装をデータ アプリケーション チームに引き渡す必要があります。 Azure テンプレート スペックなどの追加の抽象化レイヤーもオプションですが、これらのリソースを所有および維持する中央チームから必要な変更を再度要求する必要がある場合は、摩擦点の数を増やすだけです。 その後、中央チームは、変更をテストしてリリースするためにアクションを実行する必要があります。 さらに、テンプレート スペックの他のコンシューマーに影響を与えないために、より複雑なリリース管理プロセスが必要になる可能性があります。最後に、テンプレート内で特定の変更を適用するために各チームが異なるパラメーターを公開する必要が生じるように、テンプレートは時間の経過と同時に複雑になります。 そのため、データ アプリケーション チームは必要に応じて必要な変更を行えるので、参照パターンを引き継ぐのが最も簡単で最も効果的なソリューションです。 これらのチームを IaC の概念に公開することは、時間がかかる可能性がある優れたアプローチですが、最終的にはデータ プラットフォーム全体でエンジニアリングプラクティスが向上します。
詳細については、クラウド規模で分析をスケーリングすることに関するページを参照してください。