Hey there,
It’s with great pleasure that I can announce that Score has officially been accepted accepted as a CNCF Sandbox project. The committee made the decision on July 8, 2024, and we’ve started handing over the code and rights last week. Reason enough to focus this newsletter on how we’ll double down on open source and why I believe scaling platforms can only happen if we’re relying on open industry standards. Before we do this - let’s explore Score a bit!
How it started
The workload specification was started by a group around Susa Tünker at Humanitec as an environment agnostic format describing the general relationship between workloads and their dependent resources. Here’s why we funded this initiative:
- We believe that abstraction layers are something good. They form the basis of golden paths, they reduce cognitive load, and they allow you to standardize the underlying infra estate. But abstractions should not be opaque - you should be able to see through them and if need be (and your security posture allows) you should be able to circumvent them.
- Between 2018 and 2022 we observed concerning trends in how developers accepted user interfaces presented to them. The adoption rates across larger estates were very low. In interviews, developers clearly remarked that they do not want interface changes and stay as code.
- We don’t think platform technology should leave traces on the output and it should accept only industry standard input (IaC, workload spec, etc) and output only industry standards (manifests, IaC, etc). The problem was there was no industry standard workload spec so we had to create one.
Out of those requirements Score was born. A Score file sits next to the workload source code and replaces all other config formats. Score implementations transform the score file into the target platform format. Score-compose into Docker Compose, score-k8s into manifest and so forth.
Today over 90% of the requests Humanitec’s Platform Orchestrator receives are driven by Score and developer adoption rates are at an all time high.
But as I remarked not only the abstract developer input should be open source so should the rules that translate the abstract request into reality. If the Score file states that the service depends on a “cache of type Redis” and we’re deploying to staging, the platform should somehow know how to create that Redis for staging.
We’re calling those “conventions” for how a resource of a certain type is configured in a certain environment “resource definitions”. And that’s the next area that we’re heavily open-sourcing.
We’ve for instance just released Resource Definitions for the most commonly used resources in all major cloud providers and in-cluster resources. Increasingly we’re working with resource providers so they maintain their own versions. Mongo DB probably knows best how to configure Atlas in staging. In order to make consuming all definitions of a single provider convenient we’ve also released them in packs. If you want to provide your developers with the most commonly used resources for AWS all you need to do is apply the Resource Pack for AWS and all definitions are loaded.
Finally we open sourced the reference architectures as code. Those are pre-packaged Internal Developer Platforms end to end. You can use them as a starting point to build your own platform. They are now available for GCP, AWS, Azure and brand new for the Red Hat ecosystem.
All those open source components are now also neatly organized - on the brand new Humanitec marketplace.
I think Humanitec is demonstrating in action that open source matters to us. We’re staying close to our product philosophy: open industry format in, open industry format out. With Score out in the open no matter what happens to Humanitec and who has the power in our board you can rely on your workload spec to be independent.
We thank the Cloud Native Computing Foundation (CNCF) for their excellent support during the time of the handover and for their service to the community.
Kaspar
