Platform Philosophy¶
The Managed Cloud Platform is a product, not a project. Many customers run the same code, each with their own configuration, and each takes new versions at their own pace. Every rule on this page follows from that.
Principles¶
1. One codebase, many tenants¶
All logic lives in one versioned code repository (xms-cloud-platform-code). A customer's configuration repository holds
only values: mcp.json, *.auto.tfvars and JSON files. It holds no Terraform.
- A fix or feature is built once and reaches every customer through a release.
- Customer differences are expressed as configuration (feature flags, names, address ranges), never as a fork of the code.
- A request that needs new Terraform is a development change in the code repository, not a configuration change.
2. Backwards compatible by default¶
A customer must be able to take a new minor or patch version without changing their configuration and without unexpected changes in Azure. New behavior is opt-in. See Backwards compatibility for the rules.
3. Everything as code, nothing by hand¶
Every change to Azure goes through a pull request, a pipeline, a reviewed plan and an apply. A change made in the portal is drift: it is either brought into code or reverted.
4. Canary first¶
Every customer has a canary copy of the hub next to prod. Code upgrades and hub configuration changes are proven on
canary before they reach prod. Expensive canary resources can be switched off with feature flags (ADR-0006).
5. Small blast radius¶
The hub is split into layers, each with its own Terraform state. A firewall rule change can
only touch the firewall state. Every spoke has its own state.
6. Logic in the module, thin pipelines¶
All orchestration logic is in the Xebia.Mcp PowerShell module. Azure DevOps pipelines and GitHub Actions workflows only
call it, so both platforms behave the same and every step can run locally (ADR-0011).
7. Reviewable by non-Terraform people¶
Firewall rules, policies, App Gateway listeners and spokes are JSON files, validated against JSON schemas and Pester config tests before Terraform runs. A security officer can review a firewall change without reading HCL.
8. Clear responsibilities¶
The platform team owns the hub and the spoke baseline. The consumer team owns everything it builds inside its spoke. The platform team is XMMS (managed service) or the customer's own team (self-managed): see Operating models. See Consumer responsibilities and Operating responsibilities.
9. Freedom within a framework¶
Teams get autonomy where it is safe: their own pipelines, their own resources inside their spoke, and in some designs their own DNS zones. The platform sets the framework (policy, naming, network) and checks it automatically. See Design principles and DNS subdomain delegation.
What this means in practice¶
| Situation | What the philosophy tells you |
|---|---|
| A customer wants something "just for them" | Build it as an opt-in feature flag in the code repository, default off. |
| A resource must be renamed or restructured in Terraform | Add a moved block or a migration flag, so existing state is not destroyed. |
| Someone fixed something in the portal during an incident | Bring the fix into code in the same week, or revert it. Run hub in Plan mode to find drift. |
| A new version needs manual steps | Write a version-specific upgrade guide before the release goes out. See Releasing. |
| A pipeline needs a new decision (if/else) | Put it in a PowerShell function with a unit test, not in YAML. |
| A team wants more autonomy (its own firewall rule files, DNS zones, agents) | Give it a defined area with naming and policy guardrails, and let automation check it. Keep the platform team in the review loop where risk is shared (firewall, network). |
| A deviation from a standard is needed | Record it as an exception with a rationale and an end date. See Governance. |
Related reading¶
| Topic | Page |
|---|---|
| Who runs the platform (XMMS or your own team) | Operating models |
| Layers, domains, management groups, hub and spokes | Architecture reference |
| Core, direct and additional services, spoke variants | Service types |
| Roles, PIM, break-glass accounts | Identity and access model |
| Name resolution and the link with on-premises DNS | DNS design |
| Guardrails for workload teams, infrastructure and pipelines | Design principles |
| Decisions, exceptions, categories of change, service levels | Governance |
| How releases stay safe for customers | Backwards compatibility |
| Terms | Glossary |
| Design guidance: firewall rules, regions, DNS, build agents, VPN | Design guidance |