Plattform-Philosophie¶

Die Managed Cloud Platform ist ein Produkt, kein Projekt. Viele Kunden betreiben denselben Code, jeweils mit eigener Konfiguration, und jeder übernimmt neue Versionen in seinem eigenen Tempo. Jede Regel auf dieser Seite folgt daraus.

Prinzipien¶

1. Eine Codebasis, viele Tenants¶

Die gesamte Logik liegt in einem versionierten Code-Repository (xms-cloud-platform-code). Das Konfigurations-Repository eines Kunden enthält nur Werte: mcp.json, *.auto.tfvars und JSON-Dateien. Es enthält kein Terraform.

Ein Fix oder Feature wird einmal gebaut und erreicht über einen release jeden Kunden.
Kundenspezifische Unterschiede werden als Konfiguration ausgedrückt (feature flags, Namen, Adressbereiche), nie als Fork des Codes.
Eine Anfrage, die neues Terraform braucht, ist eine Entwicklungsänderung im Code-Repository, keine Konfigurationsänderung.

2. Standardmäßig abwärtskompatibel¶

Ein Kunde muss eine neue Minor- oder Patch-Version übernehmen können, ohne seine Konfiguration zu ändern und ohne unerwartete Änderungen in Azure. Neues Verhalten ist opt-in. Die Regeln findest du unter Abwärtskompatibilität.

3. Alles als Code, nichts von Hand¶

Jede Änderung an Azure läuft über einen pull request, eine pipeline, einen geprüften Plan und ein Apply. Eine Änderung im portal ist drift: Sie wird entweder in den Code übernommen oder rückgängig gemacht.

4. Canary zuerst¶

Jeder Kunde hat neben prod eine canary-Kopie des hub. Code-Upgrades und Änderungen an der hub-Konfiguration werden auf canary erprobt, bevor sie prod erreichen. Teure canary-Ressourcen lassen sich mit feature flags abschalten (ADR-0006).

5. Kleiner Blast Radius¶

Der hub ist in layers aufgeteilt, jeder mit eigenem Terraform state. Eine Änderung an einer Firewallregel kann nur den state firewall berühren. Jeder spoke hat seinen eigenen state.

6. Logik im Modul, schlanke pipelines¶

Die gesamte Orchestrierungslogik liegt im PowerShell-Modul Xebia.Mcp. Azure DevOps pipelines und GitHub Actions Workflows rufen es nur auf, sodass sich beide Plattformen gleich verhalten und jeder Schritt lokal laufen kann (ADR-0011).

7. Auch ohne Terraform-Kenntnisse prüfbar¶

Firewallregeln, Policies, App Gateway Listener und spokes sind JSON-Dateien, die gegen JSON-Schemas und Pester- config tests validiert werden, bevor Terraform läuft. Ein Security Officer kann eine Firewall-Änderung prüfen, ohne HCL zu lesen.

8. Klare Verantwortlichkeiten¶

Das Plattform-Team verantwortet den hub und die spoke-Baseline. Das Nutzer-Team verantwortet alles, was es in seinem spoke baut. Das Plattform-Team ist XMMS (managed service) oder das eigene Team des Kunden (Eigenbetrieb): siehe Betriebsmodelle. Siehe Verantwortlichkeiten der Nutzer und Betriebsverantwortlichkeiten.

9. Freiheit innerhalb eines Rahmens¶

Teams bekommen Autonomie dort, wo sie sicher ist: eigene pipelines, eigene Ressourcen innerhalb ihres spokes und in manchen Designs eigene DNS-Zonen. Die Plattform setzt den Rahmen (Policy, Namen, Netzwerk) und prüft ihn automatisch. Siehe Designprinzipien und DNS-Subdomain-Delegation.

Was das in der Praxis bedeutet¶

Situation	Was die Philosophie dir sagt
Ein Kunde möchte etwas „nur für sich“	Baue es als opt-in feature flag im Code-Repository, Default aus.
Eine Ressource muss in Terraform umbenannt oder umstrukturiert werden	Füge einen `moved`-Block oder ein Migrations-Flag hinzu, damit der bestehende state nicht zerstört wird.
Jemand hat während eines Incidents etwas im portal behoben	Übernimm den Fix noch in derselben Woche in den Code oder mache ihn rückgängig. Führe `hub` im Plan mode aus, um drift zu finden.
Eine neue Version braucht manuelle Schritte	Schreibe einen versionsspezifischen Upgrade-Leitfaden, bevor der release rausgeht. Siehe Releasing.
Eine pipeline braucht eine neue Entscheidung (if/else)	Lege sie in eine PowerShell-Funktion mit Unit-Test, nicht in YAML.
Ein Team möchte mehr Autonomie (eigene firewall-Regeldateien, DNS-Zonen, Agents)	Gib ihm einen definierten Bereich mit Leitplanken für Namen und Policies und lass die Automatisierung prüfen. Behalte das Plattform-Team im Review, wo das Risiko geteilt wird (firewall, Netzwerk).
Eine Abweichung von einem Standard ist nötig	Erfasse sie als Ausnahme mit Begründung und Enddatum. Siehe Governance.

Thema	Seite
Wer die Plattform betreibt (XMMS oder dein eigenes Team)	Betriebsmodelle
Layers, Domänen, management groups, hub und spokes	Architekturreferenz
Core-, Direct- und Additional-Services, Spoke-Varianten	Service-Typen
Rollen, PIM, Break-Glass-Konten	Identitäts- und Zugriffsmodell
Namensauflösung und die Verbindung zum On-Premises-DNS	DNS-Design
Leitplanken für Workload-Teams, Infrastruktur und pipelines	Designprinzipien
Entscheidungen, Ausnahmen, Änderungskategorien, Service Levels	Governance
Wie releases für Kunden sicher bleiben	Abwärtskompatibilität
Begriffe	Glossar
Design-Leitfäden: firewall-Regeln, Regionen, DNS, Build-Agents, VPN	Design-Leitfäden