Glossar

Begriff	Bedeutung
MCP	Managed Cloud Platform. Das Azure-landing-zone-Produkt von XMMS. Auch der Name des Container-Images (mcp), in dem die pipelines laufen, und das Präfix des PowerShell-Moduls (Xebia.Mcp).
XMMS	Xebia Microsoft Managed Services. Entwickelt und veröffentlicht die Plattform und betreibt sie für Kunden mit einem managed-service-Vertrag.
Plattform-Team	Das Team, das die Plattform für einen Kunden betreibt: XMMS (managed service) oder das eigene Team des Kunden (Eigenbetrieb). Siehe Betriebsmodelle.
Managed service	Ein Betriebsmodell, in dem XMMS die Plattform im Rahmen eines Vertrags betreibt.
Eigenbetrieb (self-managed)	Ein Betriebsmodell, in dem der Kunde die Plattform selbst betreibt.
Nutzer	Ein workload- oder DevOps-Team, das einen spoke verwendet.
Hub	Der gemeinsame Teil der Plattform: management groups, Virtual WAN und hub, Azure Firewall, DNS, Gateways, Policies, Monitoring. Auch Cloud Platform genannt.
Spoke	Eine Azure subscription für einen workload in einer spoke-Umgebung, verbunden mit dem hub. Auch spoke canvas, application landing zone oder workload landing zone genannt.
Spoke canvas	Die Baseline, die die Plattform in einen spoke deployt: Netzwerk, Identitätsgruppen, PIM, Service Principal, Key Vault, Storage, Log Analytics. Früher ein eigenes Produkt mit eigener Version (v2.x); jetzt Teil des Code-Repositorys. Auch workload environment genannt. Siehe Spoke canvas.
Plattform-Umgebung	Eine vollständige Kopie des hub mit eigener mcp.json: canary oder prod.
Spoke-Umgebung	Der Wert environment in einer spoke-JSON-Datei: dev, tst, acc, prd, shared. Eine Plattform-Umgebung hostet spokes aller spoke-Umgebungen.
Canary	Die Plattform-Umgebung, in der jede hub-Änderung und jede neue Code-Version zuerst getestet wird.
Layer	Ein Terraform root module des hub (foundation, connectivity, firewall, identity, management, postdeployment) mit eigenem state.
Level	Die Reihenfolge, in der layers laufen (1 bis 4). Layers im selben Level können parallel laufen.
Primäre Region	Die Region in primary_region. Ressourcen, die pro Plattform-Umgebung nur einmal existieren (management groups, Policies), werden nur hier deployt.
Code-Repository	xms-cloud-platform-code. Terraform, das Xebia.Mcp module, Schemas und pipeline-Templates. Ein Repository für alle Kunden.
Konfigurations-Repository	Eines pro Kunde, zum Beispiel xms-cloud-platform-config. Nur Werte, plus die Entry-pipelines.
Entry-pipeline	Eine schlanke pipeline oder ein Workflow im Konfigurations-Repository (hub.yaml, spoke.yaml, …), die ein Template im Code-Repository aufruft.
Job runners	Die selbst gehostete Build-Infrastruktur (Managed DevOps Pool, Container Apps, ACR), auf der die pipelines laufen, deployt durch die pipeline infrastructure.
Standardänderung	Eine vorab genehmigte Änderung mit geringem Risiko und bekanntem Ablauf, etwa eine Firewallregel oder ein neuer spoke. Siehe Häufige Anfragen.
Feature flag	Eine boolesche tfvars-Variable, die ein bestehendes Plattform-Feature ein- oder ausschaltet.
Config test	Pester-Tests, die die JSON-Dateien eines Konfigurations-Repositorys validieren, bevor Terraform läuft.
Drift	Eine Abweichung zwischen Azure und dem Code, meist verursacht durch eine manuelle Änderung.
Workload	Eine fachliche Lösung, die die Plattform isoliert und der sie einen Owner gibt. Die Spitze einer Hierarchie: Team-Gruppen, ein optionales Azure-DevOps-Projekt und ein Spoke pro Umgebung.
Hub-and-spoke	Ein Netzwerkdesign, in dem ein zentraler hub die spokes verbindet. Traffic zwischen spokes, zu On-Premises und ins Internet läuft über den hub.
Secured virtual hub	Ein Virtual-WAN-hub, an den Azure Firewall mit Security- und Routing-Policies angebunden ist, sodass das Routing über die Firewall automatisch erfolgt.
Core- / Direct- / Additional-Service	Die drei Service-Typen: Basisservices, Services, die ein Team anfragen kann, und Services mit separater Vereinbarung.
Sandbox	Eine Subscription für Experimente, platziert in der management group sandbox, ohne Verbindung zum hub.
Managed Spoke	Ein spoke, für den das Plattform-Team unter einer separaten Vereinbarung auch die Workload-Ressourcen baut und pflegt.
Rule collection group (RCG)	Die erste Einheit einer Azure-Firewall-Policy. Sie enthält Rule Collections, die wiederum Regeln enthalten. Eine RCG ist eine JSON-Datei im Konfigurations-Repository.
IP group	Eine benannte Menge von IP-Adressen und -Bereichen, auf die Firewallregeln verweisen.
Guardrail	Eine Regel, die Workload-Teams befolgen müssen, möglichst technisch durchgesetzt. Siehe Designprinzipien.
Consent	Eine Entscheidungsmethode, bei der ein Vorschlag angenommen wird, wenn niemand einen berechtigten Einwand hat. Siehe Governance.
Technology Board	Eine kleine Gruppe, die über architektonische Änderungen und Ausnahmen für die Plattform entscheidet. Siehe Governance.
Standard- / Normal- / Emergency-Änderung	Die drei Änderungskategorien.
Break-glass-Konto	Ein Notfallzugangskonto, das nicht an eine Person gebunden ist und genutzt wird, wenn der normale administrative Zugriff ausfällt.
PIM	Privileged Identity Management. Vergibt Rollen und Gruppenmitgliedschaften just in time, mit optionaler Genehmigung.
Managed-VM-Modul	Optionales Modul, das VMs mit einer festen Baseline deployt (Zugriffsgruppen, Monitoring, Backup, Patching). Siehe Managed Virtual Machines.
Private DNS Resolver	Der Azure-Service, der private DNS zones für On-Premises auflöst und ausgewählte Domains an andere DNS-Server weiterleitet. Siehe DNS-Design.
RPO / RTO / MTPD	Recovery Point Objective (wie viel Datenverlust akzeptabel ist), Recovery Time Objective (wie lange die Wiederherstellung dauern darf) und Maximum Tolerable Period of Disruption. Siehe Sicherheitsklassifizierung.
AMBA	Azure Monitor Baseline Alerts. Die Alert-Initiativen, die die Plattform zuweist. Siehe So funktioniert Alerting.
Secret watcher	Eine geplante Prüfung, die vor ablaufenden Secrets und Zertifikaten von App Registrations warnt. Siehe Secret watcher.
Administrative Unit	Ein Entra-ID-Container, der begrenzt, welche Gruppen die Spoke-Deployment-Identität verwalten darf. Die Identität ist Groups Administrator auf dieser Unit, nicht im gesamten Tenant. Siehe Spoke canvas.
Spoke-Deployment-Identität	Der Service Principal, der spokes erstellt und aktualisiert: Er verschiebt subscriptions und erstellt Gruppen, Service Principals und PIM-Einstellungen. Getrennt für canary und prod.
Spoke Service Principal	Die Identität, die ein spoke für sein workload-Team erstellt, damit es damit deployen kann. Owner auf der subscription. Nutzt federated credentials oder ein Secret im Key Vault des spokes. Siehe Service principal and credentials.
PIM-Rollenzuordnung (role map)	Die eingebaute Liste von Azure-Rollen (zum Beispiel für Key Vault und Storage), die der spoke seinen Gruppen auf subscription-Ebene zuweist, dauerhaft oder PIM-eligible. Kann pro Rolle überschrieben werden. Siehe Data-plane access through PIM.
IPAM-Pool	Ein Pool von Adressraum in Azure Virtual Network Manager, aus dem eine spoke-Datei ihren Adressraum zuweisen lassen kann, statt ein festes Präfix zu verwenden.
AKS Arc (AKS on Azure Local)	Ein Kubernetes-Cluster, der auf Azure-Local-Hardware läuft und über Azure Arc verwaltet wird. Siehe AKS Platform.
Agentic Developer Portal	Ein optionales, Backstage-basiertes Portal auf der Plattform. Siehe Agentic Developer Portal.
Drift-Report	Der geplante Report der spokes, deren Plan Änderungen zeigt. Siehe Configuration drift detection.