search

cncf / tag-app-delivery

📨🚚CNCF App Delivery TAG
https://tag-app-delivery.cncf.io
Apache License 2.0
775 stars 203 forks source link

[Platforms] Platforms Def - Capabilities #279

Closed joshgav closed 1 year ago

joshgav commented 1 year ago

Review and finalize "Capabilities of platforms" section of Platforms whitepaper: https://github.com/cncf/tag-app-delivery/blob/platforms-v1alpha1/platforms-whitepaper/v1alpha1/paper.md#capabilities-of-platforms

joshgav commented 1 year ago

@taras gave feedback that we may use the term "capabilities" so much in the paper that it's distracting. I'll take a bit of responsibility for that, I often see the core of a platform as a collection of (self-serviceable) capabilities; I even explored how to build a platform from this perspective here: https://blog.joshgav.com/posts/deliver-platform-capabilities

Taras also shared that in some platforms the term "feature" may be used with the same intent as we're using "capabilities".

I'll do a review and see if we can reduce use of the term, find good synonyms and improve readability.

Comparing the terms "feature" and "capability" I favor "capability" cause it reflects the nature of the thing itself - something that adds a capability to an application. "Feature" to me means more a generic part of any product.

Thoughts? Thanks!

jkleinlercher commented 1 year ago

For me a capability is something bigger than a feature. A capability consists of multiple features.

roberthstrand commented 1 year ago

For me a capability is something bigger than a feature. A capability consists of multiple features.

I agree. Capability might be one or more features combined, and a feature might not necessarily be thought of as a capability.

E.g. secrets management is a capability that could consist of features like encryption-at-rest, automatic access to secret for platform workloads, secret sharing with external users, and so on.

joshgav commented 1 year ago

@roberthstrand @jkleinlercher

For me a capability is something bigger than a feature. A capability consists of multiple features.

E.g. secrets management is a capability that could consist of features like encryption-at-rest, automatic access to secret for platform workloads, secret sharing with external users, and so on.

I like this - just like a product has features, a platform capability has features. Perhaps we could define "features" as "properties of the implementation of a capability", WDYT? I'll try an edit pass to add this idea.

Can folks share links to other descriptions and opinions on terms like these? Thanks.

joshgav commented 1 year ago

I'd like to volunteer for editing this section (and assigned myself here in GitHub). I'm passionate about describing and distinguishing the true nature of capabilities to help teams build a thorough yet streamlined platform layer: thorough in that all capabilities apps and devs require are present, and streamlined in that the focus is on providing a conceptual capability over deploying many implementations.

ThomasVitale commented 1 year ago

I'll share here what I also wrote on Slack about this topic.

I see “capabilities” as something more generic (database provisioning, vulnerability scanning, secrets management, build service, identity management, cluster lifecycle management). For example, “pipeline service” would be a generic capability of a platform. Tekton would be a tool to implement that capability. Then, the platform could expose APIs to trigger pipelines building Java and Go applications (platform “features”, the one providing a curated experience based on one or more capabilities), but no support for .NET and NodeJS (because it’s not a requirement for the specific internal platform).

jkleinlercher commented 1 year ago

I just asked ChatGPT and this was the answer :)

A capability is a specific ability or function that a product, system, or individual possesses. It refers to what something can do. A feature, on the other hand, is a distinct attribute or aspect of a product, system, or individual. It refers to a specific characteristic or detail of something. In other words, capabilities are broader and more general, while features are more specific and detailed.

joshgav commented 1 year ago

Thanks @jkleinlercher, if ChatGPT says it then... :rofl: . I like how you introduced the term "attribute" - a "capability" is the core functionality, a "feature" is an attribute of that functionality.

Building on @ThomasVitale's example and adding one more, WDYT of something like these descriptors - not for this doc but conceptually? Can you suggest others?

Capability: "run tasks"
Features:
- "run Go build tasks"
- "run static analysis tasks"
- "run a series of tasks in a pipeline"
- "run tasks on demand"
- "run tasks on an event"
Capability: "observe running services"
Features:
- "gather traces"
- "gather metrics"
- "gather logs"
- "correlate telemetry and present in a dashboard"
AaronFriel commented 1 year ago

I'd like to add the Pulumi name & logo for the diagram in this section, likely best fitting in "provide environments and resources". In addition to being a CLI, Pulumi has the Automation API, an SDK to allow platform teams to integrate provisioning in their services, and a Kubernetes operator for provisioning via programs defined as k8s resources in YAML.

I can make a PR to add to the table under https://github.com/cncf/tag-app-delivery/issues/279, however the image is a blob and I don't want to race anyone on trying to edit the diagram in Google Docs.

Note: Comment copied from #273 as requested.

joshgav commented 1 year ago

Hi folks - PR #289 addressing several Capabilities items is now up for review, PTAL.

Next for me is to:

joshgav commented 1 year ago

@AaronFriel

I'd like to add the Pulumi name & logo for the diagram in this section, likely best fitting in "provide environments and resources".

Thanks Aaron, we definitely want to consider where Pulumi, Terraform and other cloud projects fit in a cloud platform, but for the top-level paper and diagram I propose we stick to only CNCF projects as in #289. The purpose of the examples is to help readers understand the concept, not to be a thorough list of projects; and since we have to set the line somewhere I think it's best to limit to CNCF projects. We'd plan to update the graphic accordingly once we have consensus.

However :bangbang:, I'd love your help as we follow publication of the paper by deep-diving into the list of capabilities. For each we'd identify major relevant projects and products across the industry and find synergies and opportunities for conventions and standards amongst them, along the lines of what we started at Kubecon Detroit (see https://blog.joshgav.com/posts/kubecon-platforms-review). I'd also like to verify with platform implementers if/how the Capabilites list might evolve - does it cover what they find they require? How could it better support them?

To further elaborate, we're thinking of publishing something like https://cncfmaturitymodel.netlify.app/, in which case we could eventually expand on each Capability in a subsection like the "Levels" sections there.

joshgav commented 1 year ago

Hi folks - if you can please check out #311 today - it modifies the Capabilities section along the lines we discussed here. I'll merge before the end of today March 1.

I think #311 is good enough for "v1" of the paper at least, where our main goal is to start discussing and rationalizing these capability domains.

Thanks for the discussion in this issue!