search

cncf / sandbox

Applications for Sandbox go here! ⏳📦🧪
Apache License 2.0
129 stars 21 forks source link

[Sandbox] Score #79

Closed sujaya-sys closed 2 months ago

sujaya-sys commented 8 months ago

Application contact emails

chris.stephenson@humanitec.com, susanne.tuenker@gmail.com, florian@humanitec.com

Project Summary

Score is a developer-centric and platform-agnostic workload specification.

Project Description

Score provides a developer-centric and platform-agnostic workload specification to improve developer productivity and experience. It ensures consistent configurations between local and remote environments.

Cloud-native developers often struggle with configuration inconsistencies between environments. This gets even more complicated when the technology stack in each environment is different. What if you use Docker Compose for local development but Helm Charts to deploy to the Kubernetes-based development environment? Not only do you have to figure out Docker Compose and Helm, but you need to keep them in sync.

Infrastructure centric development leads to developers having to stay on top of the tech and tools of every environment their applications run in. This often results in bottlenecks across the delivery cycle. Ensuring that a configuration change made locally is reflected appropriately in a remote environment and vice versa might end up being an intricate, multi-stakeholder endeavour.

We believe that developers shouldn’t have to fight a symphony orchestra of tech and tooling when preparing their code for its journey toward production. Instead, we advocate for a workload-centric approach to software development. This means that the platform or tools of the target environment are responsible for satisfying the workload runtime requirements rather than the other way around.

The Score specification was developed following a set of workload-centric development principles: Establish a single source of truth for workload configuration Provide a tightly scoped workload spec Implement a declarative approach to infrastructure management

Score enforces these principles by providing a platform-agnostic specification that allows developers to describe their workload runtime requirements in an accessible and declarative way. This definition can be interpreted by the target environment and used as a baseline for injecting any environment-specific parameters.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/score-spec

Project repo URL in scope of application

https://github.com/score-spec/spec

Additional repos in scope of the application

score-compose score-k8s

Website URL

https://score.dev

Roadmap

https://github.com/score-spec/spec/blob/main/roadmap.md

Roadmap context

Feature enhancements and bugs adjacent to the roadmap can be found within the following repositories:

The prioritisation of roadmap items and issues is currently guided by Project Melody (score.dev/blog/project-melody).

Contributing Guide

https://github.com/score-spec/spec/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/score-spec/spec/blob/main/CODE_OF_CONDUCT.md

Adopters

No response

Contributing or Sponsoring Org

https://humanitec.com

Maintainers file

https://github.com/score-spec/spec/blob/main/MAINTAINERS.md

IP Policy

Trademark and accounts

Why CNCF?

The CNCF has provided sponsorship for projects such as Kubernetes, Helm and Docker Compose, all of which have existing Score implementations. Therefore, it appears reasonable to us to contribute Score to the CNCF, enhancing the likelihood of additional implementations being created as Score gains popularity within the community.

Benefit to the Landscape

As a platform-agnostic workload specification, Score has the potential to integrate with various container orchestration platforms and tools within the CNCF landscape. This empowers teams to swiftly test and adopt new tooling without burdening developers with added cognitive load.

By promoting a developer-centric and workload-oriented approach to cloud-native development, Score also sparks conversations within the platform engineering community on best practices and industry standards. It fosters discussions on concepts such as separation of concerns, abstraction and cognitive load, providing guidance for teams on their platform engineering journey.

Cloud Native 'Fit'

Score fits within the Application Definition & Image Build section of the CNCF landscape.

Cloud Native 'Integration'

Cloud Native Overlap

OAM/Kubevela: OAM and Score are often compared as both advocate for developer-centric development. The main difference lies in scope. OAM focuses on Kubernetes and the entire application including multiple workloads and related configuration. Score on the other hand is compute agnostic (the only limitation is the use of OCI containers) and only describes the workload. It assumes you already have a platform for rendering, orchestrating and managing your applications in place.

Similar projects

Landscape

No

Business Product or Service to Project separation

There is a Score implementation available for the Humanitec Platform Orchestrator (score-humanitec). The Platform Orchestrator is a SaaS product of the sponsoring company Humanitec. Score functions as the abstraction layer for developers that works hand in hand with the Orchestrator, but it is important to understand there is no overlap between Score and the Platform Orchestrator itself and Score can be used entirely independently of Humanitec.

Project presentations

We would be happy to schedule another presentation.

Project champions

Josh Gavant

Additional information

No response

joshgav commented 8 months ago

We've invited Score to present to TAG App Delivery's WG Platforms on Tuesday 1/23. They previously presented to the TAG last January. I'll share links to both presentations and notes afterwards.

sujaya-sys commented 7 months ago

Thank you for having us! Mathieu and I enjoyed the discussions following our presentation at the TAG App Delivery's WG Platforms meeting.

For reference:

Thanks again and please feel free to reach out with further questions or feedback.

angellk commented 5 months ago

@dims Score would be a good candidate project, in addition to others, for the Exploratory Group - or Working Group - for Infrastructure Lifecycle mentioned in the Exploratory Groups issue.

sujaya-sys commented 5 months ago

@angellk @dims Let us know if we can be of any help with figuring out which working group Score is most suitable for. One note upfront: As a platform-agnostic workload spec Score is not directly involved with infrastructure lifecycle management. Given its focus on improving the developer experience within Internal Developer Platforms, a AppDev or Platform related working group might be a good fit. Curious to hear your thoughts on this. Thanks!

jberkus commented 3 months ago

TAG-CS Note, Score currently has:

jberkus commented 3 months ago

Question:

Score describes itself as a specification, but I can't find any evidence of a specification process in your repositories. Are you using the word "specification" here in some other sense, to represent a piece of software, rather than a specification per se?

sujaya-sys commented 3 months ago

Question:

Score describes itself as a specification, but I can't find any evidence of a specification process in your repositories. Are you using the word "specification" here in some other sense, to represent a piece of software, rather than a specification per se?

Hi @jberkus, the Score specification schema can be found in the schema repository. A more human readable version is available in our developer documentation. We now added a note to the org's README to make this a little more clear, thank you for the pointer!

As for the contributing and governance guide it’ll be great to get your feedback on how we could improve. I set up a draft PR for a governance document to iterate on and hopefully publish soon!

sujaya-sys commented 3 months ago

@jberkus  A brief update on my message above:

If you have any feedback, please let us know.

Additionally, I wanted to provide an update on our progress since the TAG App Delivery's WG Platforms meeting we attended back in February: We've released two revamped reference implementations for score-compose and score-k8s, serving as blueprints for external contributors to build their own implementations and resource provisioners. At the moment, we’re collaborating with community members on implementations for fly.io, Cloud Run, AWS and Azure Container Apps. We’ve been receiving great feedback and engagement from everyone and believe that donating this project to the CNCF will boost adoption and contributions further.

mrbobbytables commented 3 months ago

Follow-up from today's sandbox review, Score will be moved to a vote, but more information was desired from the TOC. @rochaporto has been assigned to check-in with you.

/vote

git-vote[bot] commented 3 months ago

Vote created

@mrbobbytables has called for a vote on [Sandbox] Score (#79).

The members of the following teams have binding votes: Team
@cncf/cncf-toc

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor Against Abstain
👍 👎 👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 2months 30days 2h 52m 48s. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

rochaporto commented 3 months ago

@sujaya-sys the TOC reviewed the project on June 11th.

The decision was to move to a vote, but some additional clarifications were requested in any case. Specifically:

sujaya-sys commented 3 months ago

@rochaporto that's great to hear! I added my answer to your questions below. Please let me know if anything is unclear, and I'd be happy to follow up.

The main repo pointed in the submission is a specification, and the github org description also describes it as a workload specification. But there are several implementations (compose, k8s) and a library repo. Could you expand on what the core score components are and what is being submitted to sandbox?

We're submitting the entire Score org to the sandbox. This includes the core component of Score, which is the specification (represented by the spec repo). It is intended that people adopt the spec and build their own implementations.

The compose & k8s implementations included in the GitHub org are reference implementations that have only recently been made more generally useful. Their purpose is to drive adoption and serve as a blueprint for the community on how to work with the Score spec and build their own implementation.

Any community-built implementations are expected to be hosted and maintained by their creators. These can be referenced in our documentation if desired or remain as IP that is not shared. If a contributor wishes to donate their implementation to our project, we are open to exploring that option as well.

To further support the community, we maintain additional repos such as score-go, which provides shared utilities for consistency across implementations, or docker-robot-framework, which offers an example of how to implement e2e tests for your implementation. These are included as supporting repositories in our submission.

The spec repo shows very high engagement (7.6k stars, 2.2k forks), with the implementations showing significantly less. Is there an explanation for this? We would expect it to be the opposite way

The spec repo serves as the main landing page for Score, which is why we direct people there for updates and information on the project, resulting in higher engagement. The stars and forks on the implementation repositories better reflect actual usage.

For context: When we launched Score in 2022, the idea of a workload specification resonated well, attracting interest to the spec repo. A series of public engagements eventually led to the repo trending on GitHub, which further increased engagement numbers in terms of stars and forks. However, the implementations were in a proof-of-concept stage at the time, used mainly for training and demos. With the release of score-compose v2 and a new score-k8s implementation, now offering user-friendly and scalable solutions, we anticipate increased adoption and usage of these repositories.

mrbobbytables commented 3 months ago

/check-vote

git-vote[bot] commented 3 months ago

Vote status

So far 18.18% of the users with binding vote are in favor (passing threshold: 66%).

Summary

In favor Against Abstain Not voted
2 0 0 9

Binding votes (2)

User Vote Timestamp
angellk In favor 2024-06-12 16:47:34.0 +00:00:00
TheFoxAtWork In favor 2024-06-12 20:51:23.0 +00:00:00
@dims Pending
@rochaporto Pending
@mauilion Pending
@linsun Pending
@dzolotusky Pending
@kevin-wangzefeng Pending
@cathyhongzhang Pending
@nikhita Pending
@kgamanji Pending

Non-binding votes (5)

 | User | Vote | Timestamp | | ---- | :---: | :-------: | | johanneswuerbach | In favor | 2024-06-11 21:47:54.0 +00:00:00 | | jayonthenet | In favor | 2024-06-12 6:52:07.0 +00:00:00 | | SylChamber | In favor | 2024-06-12 23:34:15.0 +00:00:00 | | dharsanb | In favor | 2024-06-13 0:16:30.0 +00:00:00 | | mathieu-benoit | In favor | 2024-06-13 16:52:33.0 +00:00:00 |
mrbobbytables commented 3 months ago

/check-vote

git-vote[bot] commented 3 months ago

Vote status

So far 72.73% of the users with binding vote are in favor (passing threshold: 66%).

Summary

In favor Against Abstain Not voted
8 0 0 3

Binding votes (8)

User Vote Timestamp
TheFoxAtWork In favor 2024-06-12 20:51:23.0 +00:00:00
dims In favor 2024-06-18 19:54:41.0 +00:00:00
dzolotusky In favor 2024-06-18 5:14:01.0 +00:00:00
linsun In favor 2024-06-18 15:23:33.0 +00:00:00
nikhita In favor 2024-06-18 4:34:23.0 +00:00:00
kgamanji In favor 2024-06-18 6:40:15.0 +00:00:00
rochaporto In favor 2024-06-18 7:58:25.0 +00:00:00
angellk In favor 2024-06-12 16:47:34.0 +00:00:00
@mauilion Pending
@kevin-wangzefeng Pending
@cathyhongzhang Pending

Non-binding votes (14)

 | User | Vote | Timestamp | | ---- | :---: | :-------: | | johanneswuerbach | In favor | 2024-06-11 21:47:54.0 +00:00:00 | | jayonthenet | In favor | 2024-06-12 6:52:07.0 +00:00:00 | | SylChamber | In favor | 2024-06-12 23:34:15.0 +00:00:00 | | dharsanb | In favor | 2024-06-13 0:16:30.0 +00:00:00 | | mathieu-benoit | In favor | 2024-06-13 16:52:33.0 +00:00:00 | | GProulx | In favor | 2024-06-17 18:43:10.0 +00:00:00 | | jasonouellet | In favor | 2024-06-17 18:55:23.0 +00:00:00 | | christophcrichter | In favor | 2024-06-18 7:39:01.0 +00:00:00 | | giesan | In favor | 2024-06-18 7:42:48.0 +00:00:00 | | delca85 | In favor | 2024-06-18 8:09:58.0 +00:00:00 | | Nilsty | In favor | 2024-06-18 8:10:00.0 +00:00:00 | | MartaD | In favor | 2024-06-18 8:10:05.0 +00:00:00 | | astromechza | In favor | 2024-06-18 8:10:19.0 +00:00:00 | | mattselph | In favor | 2024-06-18 12:26:28.0 +00:00:00 |
git-vote[bot] commented 3 months ago

Vote closed

The vote passed! 🎉

72.73% of the users with binding vote were in favor (passing threshold: 66%).

Summary

In favor Against Abstain Not voted
8 0 0 3

Binding votes (8)

User Vote Timestamp
@dzolotusky In favor 2024-06-18 5:14:01.0 +00:00:00
@kgamanji In favor 2024-06-18 6:40:15.0 +00:00:00
@nikhita In favor 2024-06-18 4:34:23.0 +00:00:00
@angellk In favor 2024-06-12 16:47:34.0 +00:00:00
@TheFoxAtWork In favor 2024-06-12 20:51:23.0 +00:00:00
@rochaporto In favor 2024-06-18 7:58:25.0 +00:00:00
@linsun In favor 2024-06-18 15:23:33.0 +00:00:00
@dims In favor 2024-06-18 19:54:41.0 +00:00:00

Non-binding votes (14)

 | User | Vote | Timestamp | | ---- | :---: | :-------: | | @johanneswuerbach | In favor | 2024-06-11 21:47:54.0 +00:00:00 | | @jayonthenet | In favor | 2024-06-12 6:52:07.0 +00:00:00 | | @SylChamber | In favor | 2024-06-12 23:34:15.0 +00:00:00 | | @dharsanb | In favor | 2024-06-13 0:16:30.0 +00:00:00 | | @mathieu-benoit | In favor | 2024-06-13 16:52:33.0 +00:00:00 | | @GProulx | In favor | 2024-06-17 18:43:10.0 +00:00:00 | | @jasonouellet | In favor | 2024-06-17 18:55:23.0 +00:00:00 | | @christophcrichter | In favor | 2024-06-18 7:39:01.0 +00:00:00 | | @giesan | In favor | 2024-06-18 7:42:48.0 +00:00:00 | | @delca85 | In favor | 2024-06-18 8:09:58.0 +00:00:00 | | @Nilsty | In favor | 2024-06-18 8:10:00.0 +00:00:00 | | @MartaD | In favor | 2024-06-18 8:10:05.0 +00:00:00 | | @astromechza | In favor | 2024-06-18 8:10:19.0 +00:00:00 | | @mattselph | In favor | 2024-06-18 12:26:28.0 +00:00:00 |
Cmierly commented 2 months ago

Hello and congrats on being accepted as a CNCF Sandbox project!

Here is the link to your onboarding task list: https://github.com/cncf/sandbox/issues/186

Feel free to reach out with any questions you might have!