[Sandbox] Score #79
Comments
|
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. |
|
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. |
|
@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. |
|
@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! |
|
TAG-CS Note, Score currently has:
|
|
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! |
|
@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. |
|
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 |
Vote created@mrbobbytables has called for a vote on The members of the following teams have binding votes:
Non-binding votes are also appreciated as a sign of support! How to voteYou can cast your vote by reacting to
Please note that voting for multiple options is not allowed and those votes won't be counted. The vote will be open for |
|
@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:
|
|
@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.
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 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. |
|
/check-vote |
Vote statusSo far Summary
Binding votes (2)
|
| 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 |
|
/check-vote |
Vote statusSo far Summary
Binding votes (8)
|
| 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 |
Vote closedThe vote passed! 🎉
Summary
Binding votes (8)
|
| 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 |
Application contact emails
chris.stephenson@humanitec.com, susanne.tuenker@hotmail.de, 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'
Docker Compose: Score integrates with Docker Compose (score-compose) in order to deploy containerized apps locally.
Kubernetes/Helm: Score integrates with Kubernetes (score-k8s) in order to deploy containerized apps to any Kubernetes clusters. Additionally, there is a proof of concept available for a score-helm implementation.
Dapr: Score complements Dapr nicely. Together both tools provide a strong foundation and alignment on improving the Developer Experience (see Dapr Community Call - Jan 10th and Dapr + Score at PlatformCon).
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
OAM/Kubevela (see above)
Acorn: In a previous TAG App Delivery session at KubeCon NA 2023, Score’s approach was compared with Acornfile by Acorn (https://www.youtube.com/watch?v=NZCmYRVziGY&t=10941s); while Score files and Acornfiles provide a similar developer experience, as far as we can see Acorn doesn’t enable the creation of platform-neutral implementations, as it is closely related to Acorn’s deployment framework Acorn runtime.
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
Jan 10th 2024, Community Meeting Agenda · Issue #375 · dapr/community (github.com)
https://youtu.be/NZCmYRVziGY?t=10941
https://youtu.be/8hkxHw3MKBg?si=6YNrNIn500ecn-wt&t=339
Cloud Native Live: Solve config drift across environments with Score | CNCF
We would be happy to schedule another presentation.
Project champions
Josh Gavant
Additional information
No response
The text was updated successfully, but these errors were encountered: