cncf
Engineering Platforms Blueprint: “We build our platforms the way we build our cities: over time, without a plan, on top of ruins"
Hello App Delivery friends,
I've been reviewing the Platforms white paper in conjunction with our TAG Security efforts to draft guidelines for the upcoming Automated Governance white paper. During my review, I noticed that while the white paper lays a solid groundwork on what platforms are and provides a high-level overview of the purpose and benefits, it's a bit light on the "how-to" part—like, specifics on building and running the platform, and could be more elaborate on addressing known challenges.
To contribute towards the goal of making the paper to be even more complete and impactful, I've drafted an extended revision. Some of the additions include:
- The challenges felt a bit brief to me. Noting the need for more in-depth analysis of metrics, I fleshed this out a bit more and incorporated content inspired by "Product-Focused Reliability for SRE," like criticality tiers, aiming to offer actionable insights for offered strategies to navigate those challenges
- A more detailed examination of platform maturity, referencing your other more recent publication
- Scenarios and hypothetical case studies to illustrate the application of platform engineering principles in the real world to ground the discussion
- Made an effort to unify the document's voice and eliminate repetition
- A section on step-by-step onboarding
- and more
Again, this revision is intended to enrich and broaden the scope of the white paper. I hope it sparks productive discussions and that you'll be receptive to it as a contribution once reviewed. I'm very keen to hear your thoughts.
aV
Google Doc: https://docs.google.com/document/d/1l0vBVRKpbO021YGRG6I18G4wakDDW5ONwycRRUS2xaY
As everyone settles back after KubeCon, I wanted to provide an update. I've received positive feedback and have continued to refine and expand the content. The majority of the material is now new, and the previous content has been completely rewritten. Given the extent of these changes, I've retitled the paper.
I'll continue to work on the paper while actively seeking feedback from the community. I'm also eager to join the upcoming group meetings to learn more about other projects within the TAG and ensure that this contribution aligns with the group's overall objectives.
Looking forward to your thoughts and feedback.
Thanks so much and very excited to dig into this soon!
Just to clarify my understanding, at this stage you are proposing a new piece of work rather than a V2 of the white paper?
And is your hope for this to be privately published or something that is TAG/WG published?
There is no right answer to these questions and I am very excited to see WG members engage with this regardless of if it is a WG published piece, but it is helpful to know what type of "governance" to apply to the process.
Thanks!
At this moment, it's unclear what direction this could take, and we're open to various possibilities. It could evolve into multiple things. Happy to talk those through.
The initial thought is to see if this could be a piece published by TAG/WG, especially if it sparks interest and gets the Platforms Workgroup involved. We believe this could give the work a broader platform and greater visibility within the community. We're open to discussions to refine this idea and ensure it aligns with your contribution guidelines.
Our priority is to guarantee that the work is accessible to everyone. A private publication isn't the goal; access should be open. One thing I’d like to have a conversation on is whether the Apache license, as currently applied to your publication assets, is the most suitable for content rendered in HTML or for PDF distribution. Given that documents won't compiled and run in the way software would, we’re curious about your stance on adopting a Creative Commons 4.0 license for these assets, particularly to ensure attribution.
There are a couple of things we're still working on in the draft:
- The term 'platform' has been used broadly, potentially diluting its meaning. If 'platform' can denote anything from documentation onwards, we risk rendering the concept vague. It’s crucial to define what constitutes a platform more precisely, acknowledging that a mere collection of tools does not fulfill the comprehensive role expected of a platform.
- Integrate discussion of the SLODLC framework and start to formulate a notion of a Platform Development Life Cycle.
Great to hear you are interested in collaborating on this @anvega!
So the process for this can be very very lightweight if you are targeting a blog post. This just needs to meet minimum community guidelines and is something we actively encourage publication at speed with.
On the other side is something more formal like a white paper. In this case we will need to generate enough review/support with the group which can take a few months to go through the right level of review, debate etc.
Our next community call is Tuesday April 9 at 4pm UTC, any chance you would be around to join and discuss this further? We can try to drum up some support for reviews even if you can't make it to the call!
I won't be able to join the call tomorrow with spring break and family commitments but I'll make sure to join the next one instead.