Free — no signup required

Introduction: The "Works on My Machine" Crisis

2 min read

The Configuration Gap

Every developer has lived this scenario. You spend an afternoon writing a docker-compose.yaml that spins up your API alongside a Postgres database. It works perfectly on your laptop. You push the code. The platform team looks at your Compose file and sets it aside — they can't use it. They need Kubernetes manifests: a Deployment, a Service, an Ingress, a ConfigMap, a PersistentVolumeClaim. Maybe a Helm chart on top of that. So they rewrite everything from scratch, translating your intent into their platform's language.

This translation step is the root of a class of bugs that are notoriously hard to debug: the app behaves differently in production than it did locally, not because the code changed, but because the infrastructure description changed during translation. A port number gets misread. An environment variable name is slightly different. A resource limit is set too low. These are not code bugs — they are configuration drift bugs, and they happen precisely because developers and platform teams speak different languages.

What is Score?

Score is an open-source workload specification standard created to eliminate this translation gap. Instead of writing platform-specific configuration files, developers write a single score.yaml that describes what the application needs in abstract, platform-neutral terms. Score implementations — CLI tools — then translate that single file into whatever the target platform requires.

  • Running locally? score-compose translates score.yaml → docker-compose.yaml.
  • Deploying to Kubernetes? score-k8s translates score.yaml → Kubernetes manifests.
  • Using a different orchestrator? A custom Score implementation can target any platform.

The developer writes the specification once. The platform team owns the translation tooling. Neither has to compromise.

Why This Matters at Scale

In a monolith, one team owns the whole stack and the configuration drift problem is manageable. In a microservices organization with dozens of teams and hundreds of services, every team maintaining their own Kubernetes YAML is a compliance and reliability nightmare. Score creates a contract: the developer declares intent, the platform fulfills it. This separation of concerns is the same principle that makes APIs powerful — you call a function without caring how it's implemented.

Interview Tip

Interviewers at platform-engineering-focused companies often ask: "How do you reduce the cognitive load on developers who shouldn't need to understand Kubernetes internals?" Score is a strong, concrete answer. Frame it as a contract boundary: developers own the score.yaml (the what), platform engineers own the Score implementation (the how). This maps directly to the Platform Engineering principle of treating the platform as a product with a well-defined API.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free