-
Are the configuration files generated by Score deployment-ready?
-
What do I need to know about the Score Specification before getting started?
-
What's the difference between Score and the Score Implementation?
This depends on the complexity of your set-up. The "Hello World" guides for score-compose and score-helm allows you to directly deploy a workload. In more complex use cases, however, it is likely that the configuration generated by Score is combined with additional configuration provided by a platform or operations team. This allows for a clean separation of concerns between the developer owned workload related configuration and operations owned platform - and infrastructure related configuration.
To understand what this means in practice, the following needs to be considered:
Score only describes workload level properties. This means, if you’re deploying to an environment that runs on a system such as Kubernetes, you’ll likely have additional platforms and environment-specific configuration in place.
For example: You might want to set up namespace.yaml and ingress.yaml files for the deployments. Score assumes that any configuration outside the workload (and developer) scope is defined and managed externally, for example by an operations team. This allows you to combine the configuration generated by Score with more advanced infrastructure configuration if needed and doesn’t limit teams in leveraging the full potential of their platforms.
The Score Specification is defined in an environment-agnostic way. This means environment-specific parameters (such as variable values and secrets) need to be injected in the target environment.
For example: In your development environment, a database connection string such as: postgres://${postgres.username}:{postgres.password}@${postgres.host}:${postgres.port}/${postgres.name} might be resolved to postgresql://admin:password@group_db_host.example.com:1521/db.example.com while in staging and production you’ll want to have different credentials to be inserted. How, and from where these values are injected, is up to the platform in the target environment.
Score allows users to define resource dependencies for their service. It does not declare by whom, when and how the resource should be provisioned and allocated in the target environment. It is up to the Score Implementation to resolve the resource by name, type, or any other meta information available. For example: a dependency on a Postgres database could be resolved by a Docker image, a mock service, Terraform, a custom provisioning script or even a manual action - it is totally up to the platform (team).
If you’d like to learn more about the philosophy behind our way of separating concerns, I recommend reading the article Why we advocate for workload-centric over infrastructure-centric development.
If you have questions related to Score, its capabilities, use cases, or adoption, you can contact us anytime on Slack, GitHub, or email.
You can get started by visiting our docs.
The Score Specification file is a platform-agnostic workload specification which can be run against a Score Implementation (CLI) such as score-compose or score-helm to generate a platform configuration file such as docker-compose.yaml or a helm values.yaml file. The generated configuration file can then be combined with environment-specific parameters to run the workload in the target environment.
.
Yes. score-compose and score-helm are reference Implementations that were developed by the team to demonstrate how Score could be used. Depending on your use case, you might want to write your own Implementation for - let’s say - score-ecs or score-kustomize. You can also use one of the existing Implementations and extend it according to your needs. If you’re interested in doing so, don’t hesitate to reach out, we’d be happy to collaborate.
The Score Specification is a file that describes your workload's runtime requirements. It is characterized by being:
- platform-agnostic: The Score Specification is not tied to a specific platform or tool. As a fully platform-agnostic spec can it be integrated with many container orchestration platforms and tooling such as Kustomize, Amazon ECS, Google Cloud Run, or Nomad for example.
- environment-agnostic: The score.yaml file captures the configuration that stays the same across all environments. This allows combining it with environment-specific parameters in the target environment. For example: Your Score spec might specify a parameterized database connecting string such as
postgres://${postgres.username}:{postgres.password}}@${postgres.host}:${postgres.port}/${postgres.name}which is resolved in each environment the workload is deployed to by injecting the according credentials. - tightly scoped: Score describes workload level properties. It does not intend to be a fully featured YAML replacement for any platform. Instead, it draws a line between developer-owned workload related configuration and operations-owned platform related configuration.
- declarative: Developers declare what their workload requires to run as part of
score.yaml. The platform in the target environment is responsible for resolving individual runtime requirements. This establishes a contract between dev and ops: If the requirements listed in the spec are honored, the workload will run as intended.
The counterpart of the Score Specification is a Score Implementation, a CLI tool (such as score-compose) that the spec can be executed against to generate the required configuration (such as compose.yaml).
Score is an open source, platform-agnostic, container-based workload specification. This means you can define your workload once with the Score Specification and then use a Score Implementation CLI to translate it to multiple platforms, such as Helm, Docker Compose or Google Cloud Run. Score aims to reduce developer toil and cognitive load by only having to define a single yaml file that works across multiple platforms.
Score is the specification, while the Score Implementation is the CLI tool used to translate a score.yaml file into an output of your choice.
Technically, Score can be utilized by any team running containerized applications. When wanting to understand if Score is the right solution for your team, the main thing to orient towards is whether the pain points we communicate resonate with you:
- Are you tired of fighting tech and tools when deploying your workloads from local to production?
- Does making a configuration change feel like a tedious and error-prone procedure?
- Are you often blocked and rely on other (ops) engineers to help you out?
From our experience, this is often the case in medium-sized and larger development teams that work in a continuously growing production landscape. For example, bottlenecks and knowledge silos can arise when teams deal with the adoption of new tech and tools while maintaining legacy systems.
Score does not intend to be a fully featured YAML replacement for platforms, it only aims to define workloads that can be combined with more advanced YAML configurations that an infrastructure team would provide to developers in an organization.
Using Score provides the following advantages:
- The developer only needs to learn the Score Specification to define the workloads that run across various platforms.
- The Score Specification is designed to be applied to multiple environments to reduce the amount of configuration.
- An infrastructure team can help define and configure the resources and multiple platforms where the developer can work on.
Score provides a single, easy to understand specification for each workload that describes its runtime requirements in a declarative manner. The score.yaml file allows generating configuration in an automated, standardized and one directional way. By reducing the risk of wrongly specified or inconsistent configuration between environments, we hope to foster focus and joy for developers in their day-to-day work.