Score：CNCF 沙盒工具助力基础设施优先开发_AI阅读总结 — 包阅AI

The open source project Score does not only serve as a platform-oriented tool for developers to simplify Kubernetes deployments. It does not only function solely as a policy-setting and control mechanism using so-called guardrails. It does not only operate as an all-encompassing portal, relying mainly on graphical interfaces as a developer project.

Instead, Score — a recently accepted Cloud Native Computing Foundation (CNCF) sandbox project — is an ambitious open source effort for what its creators in the documentation describe as “infrastructure-centric development.” In other words, it’s the antithesis from not so long ago when developers would write their code and then “throw it over the fence,” for the backend folks to deploy and handle everything else. It was created by Humanitec. Susa Tünker, a product manager at Humanitec and a Score contributor, told me during a Zoom call: “We always say with Score, you can pass it through the fence rather than throwing it over.”

The idea is really about having developers better focus on getting their workload running easily and not getting distracted by infrastructure concerns, Tünker said. “Proof is about improving the developer experience and operations experience because it’s going beyond, for the operations folks, just configuring the policy and even security considerations,” she said.

With Score, the runtime spec is set so that when the developers do their work, the code is already compatible with the endpoints where the software or code is going to be deployed, whether it’s on Kubernetes, a monolith or other types of environments, Tünker said. It’s not quite a framework nor a compiler, but improving the developer experience in measurable ways is a key goal for Score’s creators.

“For developers, their experience is streamlined because it’s simpler. They are primarily concerned with developing the application and getting it to work within the confines of predetermined specifications,” Tünker said. “This setup goes beyond just policy and security aspects, simplifying other, more complex things that weren’t necessarily tied to application development. There is, for example, a single Helm chart or YAML file to configure about, as opposed to several.”

Locally, developers might use Docker for their development environment. However, as the workload is shipped to further environments for staging or production, it is likely to run on Kubernetes with Helm or similar tools. “This is where a gap arises,” Tünker said. Developers, who are often quite familiar and comfortable with Docker, may struggle when required to adjust their Helm charts to match their Docker configurations. “This discrepancy leads to increased cognitive load, as developers must adapt to a different setup for deployment. The local development environment with Docker may work well, but the challenge often lies in the transition to and management of subsequent stages,” Tünker said.

In short, it’s more of an open platform for different types of environments, as opposed to something just for specific types of environments.

The Specs

According to the project’s documentation, 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, its creators say.

For platform engineers or operations teams when running a workload that depends on a Postgres database, translation issues can be remedied. Locally, it might be a Postgres image, whereas remotely, it might be a Terraform file.

“We recently introduced the concept of resource provisioners here. It depends on our responsibilities, but either the developer or, more likely, the platform operation teams would define how to provision resources within this resource provisioner file to standardize that across environments,” Tünker said.

“Score essentially defines workload runtime requirements. It’s like a workload as a container, with resource limits, environment variables and a dependency on a database,” Tünker said. “That is the intention of the score specification: to express workload runtime requirements in a really easy way. There is no need to know how that works in Kubernetes or Docker — it’s very straightforward.”

Policies can be applied to the platform. For example, a schema can be put in place to ensure certain values or areas are not editable, building on top of the baseline provided. The baseline is a simple spec that describes what the workload needs to run. Security and policy can be enhanced with additional plugins.

“Score was defined to find a middle ground because the tool can be used by both application developers and platform teams or ops teams, providing a common ground for both to communicate,” Tünker said.

Infrastructure as code relies on templates or frameworks for developers and operations teams to create infrastructure. Score might be thought of as code for an abstraction layer that mainly targets developers regardless of the platform or infrastructure environment. It differs from so-called developer portals since developers work in code and not through graphics-based UIs. The developer experience with Score remains consistent with a single YAML file that is simple, easy to understand, and easy to learn, its creators say. “When discussing infrastructure as code, this creates an abstraction layer targeting infrastructure,” Tünker said.

Biz Model

Humanitec does not apply the company’s business model to Score. This project is not just being sold or having an enterprise version thrown on top of it. This approach to open source projects is interesting.This is an open source project, where competitors and various other companies might, or hopefully will, contribute to it. However, the project is not being used as a basis for an enterprise version to be sold.

In the meantime, Score is in its early stages of development. It will be interesting to see how the project takes shape as contributors that do not necessarily represent platforming engineering tools and platform providers adopt and contribute to the platform. Indeed, depending on how it works out, any organization that creates and deploys software could be interested.