Platformfilosofie¶
Het Managed Cloud Platform is een product, geen project. Veel klanten draaien dezelfde code, elk met een eigen configuratie, en elke klant neemt nieuwe versies in een eigen tempo af. Elke regel op deze pagina volgt daaruit.
Principes¶
1. Eén codebase, meerdere tenants¶
Alle logica zit in één geversioneerde coderepository (xms-cloud-platform-code). De configuratierepository van een klant bevat
alleen waarden: mcp.json, *.auto.tfvars en JSON-bestanden. Er zit geen Terraform in.
- Een fix of feature wordt één keer gebouwd en bereikt elke klant via een release.
- Verschillen tussen klanten worden uitgedrukt als configuratie (feature flags, namen, adresbereiken), nooit als een fork van de code.
- Een aanvraag die nieuwe Terraform nodig heeft, is een ontwikkelwijziging in de coderepository, geen configuratiewijziging.
2. Standaard achterwaarts compatibel¶
Een klant moet een nieuwe minor- of patchversie kunnen nemen zonder de configuratie aan te passen en zonder onverwachte wijzigingen in Azure. Nieuw gedrag is opt-in. Zie Achterwaartse compatibiliteit voor de regels.
3. Alles als code, niets met de hand¶
Elke wijziging in Azure gaat via een pull request, een pipeline, een gereviewde plan en een apply. Een wijziging in de portal is drift: die wordt óf in code opgenomen óf teruggedraaid.
4. Eerst canary¶
Elke klant heeft naast prod een canary-kopie van de hub. Code-upgrades en wijzigingen in de hubconfiguratie worden eerst op
canary bewezen voordat ze prod bereiken. Dure canary-resources kunnen met feature flags worden uitgezet (ADR-0006).
5. Kleine blast radius¶
De hub is opgedeeld in layers, elk met een eigen Terraform state. Een wijziging van een firewallregel
kan alleen de firewall state raken. Elke spoke heeft een eigen state.
6. Logica in de module, dunne pipelines¶
Alle orkestratielogica zit in de Xebia.Mcp PowerShell-module. Azure DevOps pipelines en GitHub Actions workflows roepen die alleen
aan, zodat beide platformen zich hetzelfde gedragen en elke stap lokaal kan draaien (ADR-0011).
7. Reviewbaar voor mensen zonder Terraform-kennis¶
Firewallregels, policies, App Gateway listeners en spokes zijn JSON-bestanden, gevalideerd tegen JSON-schema's en Pester config tests voordat Terraform draait. Een security officer kan een firewallwijziging reviewen zonder HCL te lezen.
8. Duidelijke verantwoordelijkheden¶
Het platformteam is eigenaar van de hub en de spoke-basis. Het afnemersteam is eigenaar van alles wat het in zijn spoke bouwt. Het platformteam is XMMS (managed service) of het eigen team van de klant (zelfbeheer): zie Beheermodellen. Zie Verantwoordelijkheden van afnemers en Operationele verantwoordelijkheden.
9. Vrijheid binnen een kader¶
Teams krijgen autonomie waar dat veilig is: hun eigen pipelines, hun eigen resources binnen hun spoke en in sommige ontwerpen hun eigen DNS-zones. Het platform stelt het kader vast (policy, naamgeving, netwerk) en controleert dat automatisch. Zie Ontwerpprincipes en DNS-subdomeindelegatie.
Wat dit in de praktijk betekent¶
| Situatie | Wat de filosofie je vertelt |
|---|---|
| Een klant wil iets "alleen voor hen" | Bouw het als opt-in feature flag in de coderepository, standaard uit. |
| Een resource moet in Terraform worden hernoemd of herstructureerd | Voeg een moved block of een migratieflag toe, zodat bestaande state niet wordt vernietigd. |
| Iemand heeft tijdens een incident iets in de portal opgelost | Neem de fix in dezelfde week op in code, of draai hem terug. Draai hub in Plan-modus om drift te vinden. |
| Een nieuwe versie vraagt om handmatige stappen | Schrijf een versiespecifieke upgradehandleiding voordat de release uitgaat. Zie Releasen. |
| Een pipeline heeft een nieuwe beslissing nodig (if/else) | Zet die in een PowerShell-functie met een unit test, niet in YAML. |
| Een team wil meer autonomie (eigen firewallregelbestanden, DNS-zones, agents) | Geef het een afgebakend gebied met guardrails voor naamgeving en policy, en laat automatisering dat controleren. Houd het platformteam in de reviewloop waar risico gedeeld wordt (firewall, netwerk). |
| Een afwijking van een standaard is nodig | Leg die vast als uitzondering met een motivatie en een einddatum. Zie Governance. |
Verder lezen¶
| Onderwerp | Pagina |
|---|---|
| Wie het platform beheert (XMMS of je eigen team) | Beheermodellen |
| Layers, domeinen, management groups, hub en spokes | Architectuurreferentie |
| Core, direct en additional services, spoke-varianten | Servicetypen |
| Rollen, PIM, break-glass-accounts | Identiteits- en toegangsmodel |
| Naamresolutie en de koppeling met on-premises DNS | DNS-ontwerp |
| Guardrails voor workload teams, infrastructuur en pipelines | Ontwerpprincipes |
| Beslissingen, uitzonderingen, wijzigingscategorieën, service levels | Governance |
| Hoe releases veilig blijven voor klanten | Achterwaartse compatibiliteit |
| Termen | Woordenlijst |
| Ontwerprichtlijnen: firewallregels, regio's, DNS, build agents, VPN | Ontwerprichtlijnen |