Agentic Developer Portal¶
Das Agentic Developer Portal ist ein Self-Service-Webportal für die Azure-Umgebung einer Organisation. Es basiert auf Backstage und zeigt an einem Ort, welche workloads es gibt, wem sie gehören, was sie kosten, wie sicher und konform sie sind und was die Netzwerkschicht blockiert. KI-Agenten im Portal beantworten Fragen zu diesen Daten und bereiten Konfigurationsänderungen als pull requests vor. Dieselben Aktionen stehen dem Editor der Entwicklerin oder des Entwicklers über das Model Context Protocol (MCP) zur Verfügung.
Das Portal läuft in der eigenen Azure-Umgebung des Kunden. Eine gemeinsame Code-Basis wird einmal pro Kundenumgebung deployt, sodass jeder Kunde dasselbe Image betreibt und neue Features über releases erhält. Im Quell-Repository trägt das Produkt den Arbeitsnamen Cloud Command. Du kannst diesen Namen in Ressourcennamen, Agent-Anweisungen und im Repository sehen.
Optionales Angebot
Das Portal ist nicht Teil des MCP-Kerns aus hub und spoke. Es ist ein Add-on, das neben der Plattform steht und aus ihr liest. Ob es für dich verfügbar ist, welche Features aktiviert sind und wie es vertraglich geregelt ist, hängt von deiner Plattform und deiner Vereinbarung ab. Frag dein Plattform-Team. Die Seiten hier beschreiben das Referenzdesign. Dein Deployment kann abweichen. Operatoren: Beginnt mit Architektur und Einen Kunden onboarden.
Für wen es ist¶
| Zielgruppe | Wofür sie es nutzen |
|---|---|
| Plattform- und DevOps-Engineers | Alltägliche Fragen zu workloads, Domänen, Netzwerk-Blockaden, Security-Empfehlungen und Policy-Compliance, ohne ein Ticket zu erstellen. KI-Agenten und der MCP-Server für wiederkehrende Konfigurationsarbeit. |
| Security- und Compliance-Verantwortliche, Domänen- und Abteilungsleitungen | Der Security Score und der Compliance-Status ihrer Teams, mit Übersichtsansichten als Einstieg und Details darunter. |
| FinOps und Kostenverantwortliche | Monatliche Azure-Kosten pro subscription, workload, Team und Domäne. |
| Das Plattform-Team | Das Portal für eine oder mehrere Kundenumgebungen deployen, konfigurieren und betreiben. |
Was du bekommst¶
| Bereich | Was es tut | Seite |
|---|---|---|
| Catalog | Workloads, Domänen, Teams, Organisationen und ihre Beziehungen, aufgebaut aus Azure-tags, Entra ID und Repository-Dateien | Catalog und Entity-Modell |
| Cost Insights | Azure-Kosten pro subscription, workload, Team und Domäne, im FOCUS-Schema | Insights |
| Network Insights | Blockierte Firewall-Anfragen und Application-Gateway-WAF-Logs pro workload | Insights |
| Security Insights | Microsoft Defender for Cloud Secure Score und Empfehlungen, aggregiert pro Scope | Insights |
| Compliance Insights | Regulatory-Compliance-Standards (Azure Policy) als Matrix pro Scope | Insights |
| KI-Agenten | Ein Commander-Agent plus Skills für Änderungen an spokes und der Integrationsplattform | KI-Agenten |
| MCP-Server | Die Aktionen des Portals für deine IDE und für andere Agenten, plus eine Inspector-Seite | MCP-Server |
| Module Registry | Terraform-Module aus einer angebundenen Registry durchsuchen und herunterladen | Module Registry |
| Anmeldung und Zugriff | Entra-ID-Anmeldung, eigentümerbasierter Zugriff auf sensible Details | Authentifizierung und Zugriff |
Die vollständige Liste dessen, was angeboten wird, mit Voraussetzungen und Grenzen, findest du in der Servicebeschreibung.
Umfang¶
| Im Umfang | Nicht im Umfang |
|---|---|
| Lesender Einblick in Azure-Ressourcen, Kosten, Security, Compliance und Netzwerk-Logs der subscriptions, die das Portal lesen kann | Azure-Ressourcen direkt ändern. Agenten bereiten pull requests vor, Menschen prüfen und mergen sie. |
| Catalog der workloads, Domänen, Teams und Benutzer aus Azure-tags, Entra ID und Repository-Dateien | Den Änderungsprozess der Plattform ersetzen (Eine Änderung sicher durchführen) |
| KI-Agenten und MCP-Aktionen auf diesen Daten und auf den Konfigurations-Repositories für spokes und Integration | Kundenspezifische Änderungen am Portal-Code. Eine kundenspezifische Anfrage läuft als separate Arbeit über den Solution Lead. |
| Alle Kundendaten in der Azure-Umgebung des Kunden verarbeiten | Kundendaten in der Umgebung des Anbieters speichern |
| Eine Module-Registry-Ansicht (durchsuchen, herunterladen, optional hochladen und löschen) | Die Registry selbst betreiben oder bauen |
Wie es sich zur Plattform verhält¶
Das Portal wird in einen spoke der Managed Cloud Platform deployt und liest die darüberliegende Hierarchie der management groups.
- Jede Portal-Umgebung (zum Beispiel Acceptance und Produktion) liegt in einem eigenen spoke, gebaut mit dem Spoke canvas. Sie nutzt das Netzwerk, den Key Vault und den Log-Analytics-workspace des spokes.
- Es erkennt workloads an den subscription-tags der Plattform (Namensgebung und tags) und Benutzer und Gruppen aus Entra ID. Siehe das Identitäts- und Zugriffsmodell.
- Der Spoke-Agent liest die Spoke-Konfiguration der Plattform und schlägt Änderungen daran vor (Spoke-JSON-Referenz). Die Review- und Deployment-Schritte der Plattform bleiben unverändert.
- Der Integrations-Agent arbeitet an der Konfiguration der Integration Platform.
- Die Module-Registry-Ansicht listet Module, etwa die der Managed Templates, wenn deine Registry sie enthält.
- Die KI-Modelle werden von einem Azure-AI-Foundry-Konto in der subscription des Kunden bereitgestellt. Die separate Lösung KI-Plattform ist ein anderes Angebot.
Das Portal ist ein zusätzlicher Service im Sinne der Servicetypen: Es hat einen eigenen Umfang und wird neben der Plattform-Baseline geliefert.
Betriebsmodelle¶
Das Plattform-Team, das das Portal deployt und betreibt, ist XMMS im Rahmen eines managed-service-Vertrags oder das eigene Team des Kunden, wenn die Plattform im Eigenbetrieb läuft. Siehe Betriebsmodelle.
| Workload-Team | Plattform-Team | |
|---|---|---|
| Das Portal nutzen, subscriptions mit tags versehen und workloads besitzen | Ja | |
| Pull requests prüfen und mergen, die Agenten vorbereiten | Wo sie das Repository besitzen | Ja, für die Plattform-Konfiguration |
| Das Portal deployen, konfigurieren und aktualisieren | Ja | |
| Dem Portal Lesezugriff auf Azure und Entra ID geben | Ja, mit dem Cloud-Plattform-Administrator und dem Entra-ID-Administrator des Kunden | |
| Private-Endpoint-Verbindungen für das Deployment genehmigen | Ja, auf Kundenseite |
Code und pipelines werden in der Referenzlieferung nicht übergeben
In der Referenzlieferung behält der Anbieter den Quellcode und deployt das Image aus seiner eigenen pipeline in den Kunden-Tenant. Der Kunde erhält das deployte Produkt, nicht den Code. Wie ein Team im Eigenbetrieb das Portal erhält und betreibt, ist in den Quellen dieser Seiten nicht beschrieben. Vereinbare das ausdrücklich in deinem Vertrag.
Dokumentationsübersicht¶
| Seite | Inhalt |
|---|---|
| Servicebeschreibung | Was angeboten wird, Voraussetzungen pro Feature, Grenzen |
| Catalog und Entity-Modell | Entity-Arten, tags, Zusammenführen |
| Insights | Kosten, Netzwerk, Security und Compliance |
| KI-Agenten | Die Agenten, was sie können, Guardrails |
| MCP-Server | Das Portal aus einer IDE nutzen |
| Module Registry | Terraform-Module durchsuchen und herunterladen |
| Authentifizierung und Zugriff | Anmeldung, eigentümerbasierter Zugriff |
| Architektur | Komponenten, Azure-Ressourcen, Datenflüsse, Netzwerk |
| Voraussetzungen | Was der Kunde vor dem Deployment bereitstellt |
| Einen Kunden onboarden | Runbook für das Plattform-Team |
| Deployment und Umgebungen | Terraform-roots, Umgebungsdatei, pipelines |
| Konfiguration | Feature-Flags, Zeitpläne, GitHub, Theme, Module Registry |
| Cost-Insights-Einrichtung | Kosten-Export und Ingestion-Ressourcen |
| KI-Einrichtung | Foundry, Spoke-Agent, Integrations-Agent |
| WAF und eigene Domain | Application Gateway und WAF vor dem Portal |
| Agent-Evaluierung | Wie Agenten getestet und beobachtet werden |
| Betrieb | Health, Sync, Alerting, Troubleshooting |
| Entscheidungen | Die Architekturentscheidungen in Kürze |