Overview
platform-mesh/architecture#28
This initiative re-architects Platform Mesh around an immutable minimum-viable core with independently opt-in extensions, so any deployment can run on the core alone and add only the specific capabilities it needs.
The premise is that there is a headless, minimum-viable version of Platform Mesh that is always present and effectively unchangeable — everything else binds to it, and it depends on nothing outside itself. Identifying precisely what constitutes that core is the first thing this work needs to settle. Around it sit further capabilities, layered conceptually as tiers (or onion rings) by how far they are from the core. The defining constraint is that these capabilities are optional at the item level, not the tier level: selecting one capability from an outer layer must not drag in the rest of that layer. A tier is a way to reason about coupling, not a unit of deployment.
The initiative also covers the implications of moving to this model — the architectural consequences, and an honest accounting of the upsides (smaller default footprint, clearer ownership, easier onboarding, contained blast radius) against the downsides (a larger test and support matrix, version skew, dependency-resolution complexity, and the risk that unbounded optionality erodes a coherent default). Alongside the design, it considers how this is actually implemented: what it means for the existing repository structure, including whether a mono-repo is the right move, and how someone brings up the core plus a chosen set of extensions locally.
Finally, it is an opportunity to modernize the supporting machinery rather than leave it untouched. The CI/CD setup is explicitly in scope to change as part of this — covering testing, the Renovate configuration, and how images and components are built and pulled — so the tooling supports composable, independently versioned modules rather than working against them. It is also an opportunity to reduce dependencies and manage complexity, i.e. monorepo.
The detailed breakdown into epics and tasks is deliberately left open here; that follows from the decisions taken in the referenced RFC and will be defined by the team.
Overview
platform-mesh/architecture#28
This initiative re-architects Platform Mesh around an immutable minimum-viable core with independently opt-in extensions, so any deployment can run on the core alone and add only the specific capabilities it needs.
The premise is that there is a headless, minimum-viable version of Platform Mesh that is always present and effectively unchangeable — everything else binds to it, and it depends on nothing outside itself. Identifying precisely what constitutes that core is the first thing this work needs to settle. Around it sit further capabilities, layered conceptually as tiers (or onion rings) by how far they are from the core. The defining constraint is that these capabilities are optional at the item level, not the tier level: selecting one capability from an outer layer must not drag in the rest of that layer. A tier is a way to reason about coupling, not a unit of deployment.
The initiative also covers the implications of moving to this model — the architectural consequences, and an honest accounting of the upsides (smaller default footprint, clearer ownership, easier onboarding, contained blast radius) against the downsides (a larger test and support matrix, version skew, dependency-resolution complexity, and the risk that unbounded optionality erodes a coherent default). Alongside the design, it considers how this is actually implemented: what it means for the existing repository structure, including whether a mono-repo is the right move, and how someone brings up the core plus a chosen set of extensions locally.
Finally, it is an opportunity to modernize the supporting machinery rather than leave it untouched. The CI/CD setup is explicitly in scope to change as part of this — covering testing, the Renovate configuration, and how images and components are built and pulled — so the tooling supports composable, independently versioned modules rather than working against them. It is also an opportunity to reduce dependencies and manage complexity, i.e. monorepo.
The detailed breakdown into epics and tasks is deliberately left open here; that follows from the decisions taken in the referenced RFC and will be defined by the team.