開発者向けセルフサービス プラットフォーム アーキテクチャ
開発者のセルフサービス エクスペリエンスは、カスタム ビルド、既製、オープンソースのテクノロジにまたがる概念、パターン、ツールの組み合わせに依存します。 目標は、一元的な可視性を維持しながら、開発者が管理されたタスク実行とプロビジョニングを行えるようにすることです。 主な焦点は、開発者が個別に処理するには面倒または複雑すぎるタスクに置く必要があります。
開発者向けセルフサービス プラットフォーム コンポーネント
開発者のセルフサービス基盤は、開発者ワークフローを合理化および自動化するために連携して動作するいくつかの主要コンポーネントで構成されています。 これらのコンポーネントには、 開発者プラットフォーム API、 開発者プラットフォーム グラフ、 開発者プラットフォーム オーケストレーター、 開発者プラットフォーム プロバイダー、 ユーザー プロファイルとチーム メタデータが含まれます。
Developer Platform API は、ユーザー エクスペリエンスと他のシステム間の契約上のインターフェイスとして機能する、対話の中心点として機能します。 Developer Platform API は、さまざまなユーザー インターフェイスを通じてデータ アクセスを有効にし、プロビジョニング アクションを推進する必要があります。 これはプライマリ認証とセキュリティ レイヤーとして機能し、基となる生の API へのアクセスを、対応するデータおよび操作と共に制限します。 この API は、ユーザー プロファイル、プラットフォーム内のロール、主要な ID プロバイダー識別子を管理して、適切なアクセス制御を保証します。
Developer Platform API を補完することは、プラットフォーム内のエンティティとテンプレートの検出と関連付けを容易にする、セキュリティで保護されたマネージド データ構造である Developer Platform Graph です。 エンティティは複数のソースからデータを集約し、テンプレートは自動化のためにユーザー入力をガイドします。
Developer Platform Graph を使用すると、複数のプロバイダーのエンティティとテンプレートを検索可能な構造に関連付けることができます。 これらのエンティティのデータはグラフ データベースに直接保存する必要はありませんが、プロバイダーとのやり取りは必要なメタデータとともにキャッシュできます。 このグラフは、複数のプロバイダーによって提供される共通のエンティティを操作する場合に特に役立ちます。 たとえば、API は Azure API Center から取得され、デプロイと環境は継続的デプロイ システムからプルされる場合があります。 このグラフは共通 API を通じてユーザー エクスペリエンスを強化し、検出、検索、ガバナンスを可能にします。
テンプレート ベースのアクションを実行するために、 Developer Platform Orchestrator は要求をルーティングして追跡し、ダウンストリーム システムと統合する特殊な 開発者プラットフォーム プロバイダー と連携します。 オーケストレーターを使用すると、開発者またはシステムは、アクションを直接実行することなく、テンプレートを使用してアクションを要求できます。 タスク エンジン、ワークフロー エンジン、または別のオーケストレーターと連携してアクションが実行されます。 このコンポーネントは、開発者が直接アクセス許可を必要とせずにアクションをトリガーできるため、セルフサービスを有効にするために不可欠です。 CI/CD とは異なり、これらのアクションはアプリケーションのソース コードに限定されません。 GitHub Actions や Azure Pipelines などのワークフロー エンジンはオーケストレーターとして機能しますが、抽象化は時間の経過とともにさまざまなエンジンをサポートするのに役立ちます。 この柔軟性により、エンジンの移行が可能になり、後で自動化される可能性のあるプロセスの手動ステップがサポートされ、開発以外のロール (買掛金勘定など) を対象とするアクションに対応できます。 さらに、より単純なタスクは HTTP 要求を介して処理できるため、複雑なエンジンが不要になります。
開発者プラットフォーム プロバイダーは 、エンティティに対する作成、読み取り、更新、削除 (CRUD) 操作とアクション要求の実行のロジックを管理し、多様なワークフローとサービスをサポートします。 このプロバイダーにより、拡張可能なプロバイダー モデルを通じて API に機能が導入され、自動化やデータ集計などの主要な機能が有効になります。 このモデルによって疎結合が促進され、新機能の段階的な統合が可能になり、保守性が向上します。 内製化のマインドセットを育むと、さまざまなチームによってプラットフォームの機能が提供および保守されるようになり、中央チームの保守負担を最小限に抑えることができます。 プロバイダー コードのレビューやアクセス管理を慎重に行うことは重要ですが、このプラグ可能なアプローチは組織全体に開発作業を拡大するのに役立ちます。
この基盤には 、ユーザー プロファイルとチーム メタデータを管理するための機能も含まれています。これにより、個人とチームの情報が、Microsoft Entra ID などの ID プロバイダーによってホストされているアカウントに関連付けられます。 このメタデータは、Developer Platform API 内でのグループ化とアクセス制御に使用されます。 この情報は、Developer Platform Graph に保存することもできますが、分離すると明確性が確保されます。
開発者のセルフサービス基盤には、一元化されたユーザー インターフェイス/ユーザー エクスペリエンス (UI/UX) を介してアクセスできます。 統合アクセス ポイントを提供すると、開発者のやり取りが効率化され、ワークフローとリソースをシームレスかつ直感的に使用できるようになります。
開発者のセルフサービス基盤を最初から完全に構築する必要はありません。 むしろ、それは時間をかけて目指すべき機能の概念ガイドとして機能します。 既存のツール、インターフェース、またはクラスを使用して初期実装を簡素化し、顧客からのフィードバックを通じて特定された最優先事項に対処できます。 小さく始めて反復すると、基盤は新しい需要に効果的に対応できるように進化することができます。
開発者プラットフォーム プロバイダーの主要な概念
開発者プラットフォームでは、リソースの効果的な管理とオーケストレーションは、エンティティとそのプロパティとテンプレートの使用に依存します。 これらの主要な概念は、構造と自動化を提供し、さまざまなプロバイダー間でシームレスな統合を可能にし、一貫したワークフローとガバナンスを促進します。
エンティティ
エンティティは、開発者またはシステムが内部開発者プラットフォーム内で追跡、更新、提示、または操作を行うために必要な重要なオブジェクトです。 これらのエンティティは互いに関係を持つことができ、プラットフォームに関する重要な情報を提供するグラフを形成します。 開発者プラットフォーム プロバイダーは、外部リソースの検出、依存関係分析の実行、所有権とメンテナーの情報の表示など、さまざまなコア機能をサポートするエンティティを出力できます。 明確に定義されたプロバイダー インターフェイスにより、統合、テスト、デプロイが簡素化され、開発者チームが独立して操作できるようになります。
共通プロパティ
エンティティを効果的に管理するには、共通のプロパティのセットを定義すると便利です。 一部の推奨されるプロパティには、一意の識別子、名前、発信元プロバイダー、およびオプションでユーザー、チーム、またはその他のエンティティへの関連付けが含まれます。 これらのプロパティは、ロールベースのアクセス制御 (RBAC)、検出、データ集計に重要です。 最初から RBAC を実装することは、セキュリティと時間の経過に伴うプラットフォームのスケーリングに不可欠です。 ユーザーとチームの関連付けは、検出とコラボレーションに役立つため、特に価値があり、プラットフォーム内での効率的な再利用、サポート、内製化を可能にします。
共通エンティティとプロバイダー固有のエンティティ
また、複数のプロバイダーが出力できる共通の高レベルの正規化されたエンティティのセットも定義する必要があります。 これには、環境、リソース、API、リポジトリ、コンポーネント、ツールが含まれる場合があります。 これらのエンティティは概念的なもので、細かい技術的な詳細 (内部インフラストラクチャなど) ではなく、幅広い分類 (環境など) に焦点を当てる必要があります。 この高度なビューにより、検出が容易になり、時間の経過に伴うデータ集計を可能にすると同時に、システム外の下位レベルの詳細をポイントできます。 さらに、プラットフォームの進化に伴い、さまざまなユース ケースに対応するために、プロバイダー固有のエンティティ型のセットの増加に対応することが必要になる場合があります。
テンプレート
テンプレートは、インフラストラクチャのプロビジョニング、リポジトリの作成、その他の実行時間の長いプロセスなどのアクションを実行するように設計されています。 これらのテンプレートは、開発者プラットフォーム プロバイダーを通じて入手でき、エンティティの関連付けや必要な入力 (リソース名など) などの共通プロパティが含まれています。 テンプレートは、コードとしてのインフラストラクチャ (IaC) テンプレート、アプリケーション テンプレート、パラメーター化されたスクリプトなど、さまざまな形式を表すことができます。 多くの場合、これらはプロバイダー固有で、使用中のテクノロジーによって表現が異なります。 これらの表現の例としては、Terraform または Bicep テンプレート、Helm チャート、パラメーター化された GitHub Actions ワークフロー、Azure Pipelines、単純なスクリプト、特定のプロバイダー エコシステムに合わせて調整されたカスタム形式などがあります。
テンプレートは一元的に保存する必要はありませんが、プラットフォーム全体で一貫したアクセスを確保するために、プロバイダー経由でアクセスできる必要があります。 これらは、ユース ケースに応じて、異なるリポジトリ、レジストリ、またはカタログに存在できます。 たとえば、GitHub テンプレート リポジトリはアプリケーション テンプレートに使用できますが、IaC テンプレートは、開発者が Azure Deployment Environments などのツールを介して間接的にアクセスする制限付きカタログ リポジトリに存在する可能性があります。 その他の IaC テンプレートは、Helm チャートなど、Open Container Initiative (OCI) アーティファクト レジストリに格納される場合があります。 場合によっては、テンプレートは単にパラメーター化された HTTP エンドポイントを参照する場合があります。
プラットフォーム エンジニアまたはドメイン スペシャリストは、通常、これらのテンプレートを作成し、再利用するために開発チームと共有します。 システム内でのテンプレートの使用を一元化すると、組織の標準とポリシーを適用しながらアクセスが容易になります。 このプロセスにより、プラットフォーム全体の制御とコンプライアンスを維持しながら、開発者がより効率的に作業できるようになります。
プラットフォーム プロバイダーとしての GitHub Actions
プロバイダーがどのように機能するかを説明するために、GitHub Actions と Azure Pipelines について考えてみましょう。 どちらも、開発者プラットフォーム プロバイダーとして機能するには、それぞれの API (GitHub Actions REST API や Azure DevOps Pipeline API など) を介してワークフローやパイプラインの実行をトリガーします。 これらのワークフローやパイプラインは、アプリケーションのソース コード リポジトリに格納する必要がないため、プラットフォーム エンジニアは中央のプライベート リポジトリでそれらを維持できます。 このモデルでは、開発者はワークフローに直接アクセスすることはできませんが、開発者プラットフォーム プロバイダーを使用してワークフローとやり取りできます。 このプロバイダーを Azure Key Vault などのサービスと統合すると、資格情報や API キーなどの必要なシークレットを管理できます。 ワークフローが実行されると、プロバイダーは、GitHub Actions の Webhook と Azure Pipelines のサービス フックを使用して、その進行状況を監視し、状態を追跡します。 ワークフローが完了すると、ビルドやデプロイの結果など、生成されたすべてのアーティファクトがキャプチャされ、公開されます。 これらのアーティファクトは、入力パラメーターとワークフローへの参照と共に、開発者プラットフォーム グラフに追加できます。 また、このアプローチにより、任意の CLI を柔軟に使用できるようになり、長期にわたって幅広い自動化タスクをサポートできるようになります。 さらに、このコンテキストでの GitHub Actions または Azure Pipelines の使用は、CI/CD における従来の役割とは独立しており、さまざまなプロセスやテンプレートを管理するためのより幅広い適用性を提供します。
他にも、テンプレートを使用してさまざまなタスクを処理できる開発者プラットフォーム プロバイダーがあります。 ソース管理操作の場合、プロバイダーは、一般的なワークフロー エンジンに依存することなく、リポジトリの作成、PR の送信、その他の Git 操作などの Git タスクの管理に役立ちます。 インフラストラクチャのプロビジョニングは、セキュリティと効率性を備えたコードとしてのインフラストラクチャ (IaC) に重点を置いて、Azure Deployment Environments や Terraform Cloud などの専用プロバイダーを通じて合理化できます。 Azure Developer CLI などのアプリケーション スキャフォールディング プロバイダーは、アプリケーション ソース ツリーの作成とソース リポジトリへのプッシュをサポートしており、さまざまなエコシステムに柔軟性を追加します。 pull request (PR) の生成や開発者以外のユーザー向けのワークフローの自動化などの手動プロセスは、テンプレート ベースのプロバイダーを使用して管理することもできるため、段階的な自動化が可能になります。 これらの例は、開発者プラットフォーム プロバイダーの拡張性と適応性が時間の経過とともに自動化機能をどのように強化できるかを示しています。