問題領域を定義する
社内の開発者プラットフォームの定義に向かう際には、最初に実用可能な最薄プラットフォーム (TVP) を定義する必要があります。 TVP は、従来の製品管理における実用最小限の製品 (MVP) のアイデアのバリエーションです。
この図は、開発者プラットフォームが時間の経過と共にどのように進化するかを考える際に役立ちます。 既存の投資や組織のニーズにより、組織の最も大きい問題がここで説明されているものから逸脱する可能性があることに注意してください。 組織で必要な場合を除き、次のステージに進む必要はありません。
ゼロから始める場合、これは一般的な進行を表します。 初期段階では、必要な機能の発見、市販の製品のフィットギャップ分析、および最小限の数のツールまたはプラットフォーム機能の作成に重点を置きます。 次に、スケーリングを行う際に、再利用性に重点を置き始め、再利用可能な資産を使用して事前に定義済みの整備されたパスにユーザーを誘導します。 最後に、アプリケーションの構築と保守を容易にするために、コンシューマーに似た "デジタル ストア" モデルに移行します。 製品の考え方に従う必要があるため、最後までジャンプすることはお勧めしません。具体的な体験はさまざまです。 これらの最終段階は、従来の意味で市販の "製品" に最も似ていますが、これは出発点ではなく目的地です。
プラットフォーム エンジニアリングのトピック領域
このトピックの規模がとても大きかったので、プラットフォーム エンジニアリングについて社内で話す方法を 4 つのトピック領域に分割することをお勧めします。
エンジニアリング システム: GitHub や Azure DevOps などの DevOps スイートと、その他の開発者ツールとサービスの厳選された組み合わせ。 CI/CD や Package Management などの重要な DevOps ツールやサービスだけでなく、この領域には、クラウドベースのコーディング環境、コード スキャナーとリットル、GitHub Copilot のような AI アシスタントなどのコーディング プロセス中に直接使用される機能も含まれます。
アプリケーション プラットフォーム: 組織がビジネス価値の提供に使用する各 "アプリ スタック" (アプリケーション、アプリ モデル、言語のクラス) を対象とする、厳選されたサービス (IaaS、PaaS、監視など)。 これには、アプリ スタック固有のサービスと、全体で使用される一般的なサービスの組み合わせが含まれます。 アプリケーション プラットフォームの例としては、Azure Container Apps、ストレージ用の Cosmos DB、シークレット用の Azure Key Vault、ID とロールベースのアクセス制御用、コンプライアンスと監査用の Azure Policy、Grafana による監視、関連するネットワーク トポロジなどがあります。
アプリケーション テンプレート: 明確に定義された、組織が作成したクイック スタート テンプレートのセット。開始を正しくカプセル化し、特定のアプリケーション プラットフォーム、言語、および一連のエンジニアリング システムに対して適切なガイダンスを維持します。 他の一元化されたテンプレートを参照し、スターター コード、API と SDK の参照、CI/CD パイプライン、ツール構成などを提供できます。
開発者のセルフサービス機能: これはプラットフォーム エンジニアリングの取り組みの接着剤です。 これは API、オーケストレーター、カタログ、テンプレート、およびユーザー エクスペリエンスの組み合わせであり、開発者の作業を削減し、開発チームがセルフサービスで自律的になり、前の 3 つの領域からの選択やガイダンス、ガバナンスに準拠できるように設計されています。
エンジニアリング システム、アプリケーション プラットフォーム、アプリケーション テンプレート、開発者のセルフサービス機能を統合することは、プラットフォーム エンジニアリング戦略の基礎となります。 DevOps ツール、クラウド サービス、セルフサービス機能を組み合わせることで、組織は開発者の作業を大幅に削減し、生産性を向上させ、ガバナンス標準への準拠を確保できます。