Contribution Description
As a community we are quickly racing towards a marketplace model for platform growth. With diversity of producers comes possible sprawl of implementations. The community would benefit from a shared set of factors that describe what it looks like to support platform producers to scale platform scope through contributions while keeping the platform operations maintainable. This can have a similar scope, detail, and hopefully impact as the 12-factor app did back in 2011. And like the 12-factor app, these factors should be independent of implementation allowing platforms to continue to be built with the right OSS projects and off-the-shelf products for a given organisation.
Contribution type
White paper
Why The Cloud Native Platform Engineering Community?
Background
A 'platform engineering team' is often described as the middle layer between product engineering on one side and infrastructure on the other; their domain consists of delivering capabilities that are unique to the company but common across teams that help deliver software faster, safer, and more efficiently. Many of these platform engineering teams, and disproportionately at large companies, achieve this goal by wrapping capabilities behind an API for internal customers to use. This is also sometimes referred to as an IDP, or Internal Developer Platform.
It has become clear that monolithic platform architecture can’t keep up with the scale and complexity that modern enterprises face. However, the answer also can't be a patchwork of small specialized platforms. Instead, platforms must be composed of independently packaged, on-demand capabilities, brought together through a shared interface into a coherent experience. This composable platform marketplace is a relatively novel concept, and implementations are in the "let a thousand flowers bloom" stage of development.
Related projects/technologies
n/a
Affiliation disclosure
n/a
Additional collaborators
@ChrisPlank and @krumware
Additional information
Current draft
To get the work started there has been a draft created and reviewed by over 20 community members here: https://docs.google.com/document/d/1V1ESrJ0AZagEtlknZBuhiLjJEau-8jLo5UmsdAmG9NA
Reviewers have up until now shown a lot of enthusiasm for something of this shape to exist with some really great feedback on how to evolve the draft incorporate their own experiences and needs. I have tried to incorporate these but the draft absolutely needs a more rigorous review period before it can be ready for community wide adoption.
Timeline
February 2026 - v0.0.1 gets proposed by Abby/Syntasso to see appetite in the community
March 2026 - Proposed as an official community initiative and discussion point at KubeCon EU (AMS)
TBC - Create a working group to iterate on the document
TBC - Release v0.1.0 for formal community review
TBC - Release v1.0.0 for community use
Contribution Description
As a community we are quickly racing towards a marketplace model for platform growth. With diversity of producers comes possible sprawl of implementations. The community would benefit from a shared set of factors that describe what it looks like to support platform producers to scale platform scope through contributions while keeping the platform operations maintainable. This can have a similar scope, detail, and hopefully impact as the 12-factor app did back in 2011. And like the 12-factor app, these factors should be independent of implementation allowing platforms to continue to be built with the right OSS projects and off-the-shelf products for a given organisation.
Contribution type
White paper
Why The Cloud Native Platform Engineering Community?
Background
A 'platform engineering team' is often described as the middle layer between product engineering on one side and infrastructure on the other; their domain consists of delivering capabilities that are unique to the company but common across teams that help deliver software faster, safer, and more efficiently. Many of these platform engineering teams, and disproportionately at large companies, achieve this goal by wrapping capabilities behind an API for internal customers to use. This is also sometimes referred to as an IDP, or Internal Developer Platform.
It has become clear that monolithic platform architecture can’t keep up with the scale and complexity that modern enterprises face. However, the answer also can't be a patchwork of small specialized platforms. Instead, platforms must be composed of independently packaged, on-demand capabilities, brought together through a shared interface into a coherent experience. This composable platform marketplace is a relatively novel concept, and implementations are in the "let a thousand flowers bloom" stage of development.
Related projects/technologies
n/a
Affiliation disclosure
n/a
Additional collaborators
@ChrisPlank and @krumware
Additional information
Current draft
To get the work started there has been a draft created and reviewed by over 20 community members here: https://docs.google.com/document/d/1V1ESrJ0AZagEtlknZBuhiLjJEau-8jLo5UmsdAmG9NA
Reviewers have up until now shown a lot of enthusiasm for something of this shape to exist with some really great feedback on how to evolve the draft incorporate their own experiences and needs. I have tried to incorporate these but the draft absolutely needs a more rigorous review period before it can be ready for community wide adoption.
Timeline
February 2026 - v0.0.1 gets proposed by Abby/Syntasso to see appetite in the community
March 2026 - Proposed as an official community initiative and discussion point at KubeCon EU (AMS)
TBC - Create a working group to iterate on the document
TBC - Release v0.1.0 for formal community review
TBC - Release v1.0.0 for community use