Hey,
Ultimately, platform engineering is about designing golden paths and providing interfaces for developers to consume. But if we ask 10 platform engineers to describe a golden path, the chances are we’ll likely get the same answer: “It’s when a developer uses the scaffolding workflow in a portal, a template gets cloned, and we have a highly standardized new microservice with a database etc.”.
That’s not explicitly wrong. This, indeed, is a golden path, albeit a static one. If you’re using this method, you have exactly one golden path for every service—across its entire lifetime! Let me outline some design flaws with this approach:
- If you’re standardizing only at the start of a service/resource lifetime, you’re enforcing security, compliance, and standards for seconds until the configs start drifting. Best practices? Maybe for a minute. That’s better than nothing, but it’s not the optimal answer.
- How often do you scaffold a new service? I work with 2,000 + developers, and if you zoom into the individual teams, the creation of a new service is a rare event. Why optimize so heavily on this one case?
- This path is as good as its templates. But how do you know what resource combination your developers will request? Springboot, sure. But with what DB? In what configuration? Need S3? Real life is hard to predict, and so pre-templated, static golden paths are unlikely to really match the needs of the team.
So how do you design platforms that solve these issues? Can we create many golden paths across the entire lifetime of a service and resource? The answer is, of course: Yes! Let's think about this conceptually,
If we could “standardize” with every single release, we could put people on golden paths with every single deployment. Ha, brilliant! But how do we do this? By using Dynamic Configuration Management and thus by creating app and infrastructure configurations just in time with the deployment.
Let's be more concrete and think about a very specific situation. You’re a developer, and you have an existing service. Now you need an S3 bucket. You know the drill in your setup today. Write the Terraform, get the resource. If you’re compliance-heavy, you then let security check it. You wire the env vars, deal with secrets etc., and when you’re done, you repeat at least twice for the other environments. Then you push and pray. That’s not a golden path.
In this example, a golden path would look like this:
- Open a workload specification, Score, for instance.
- Add exactly two lines:
- Storage:
- Type: s3
- Now git-push through your normal CI/CD flow and use the tag to indicate that the env=dev;
- S3 bucket will be created, and credentials will be automatically injected.
Wow! Isn’t that crazy? Now it’s running in your dev environment. Same file, git-push with context = staging, and voila. It’s up and running and fully wired in staging.
THIS is what I call a golden path. Golden paths are also not only for devs, they are just as much for platform engineers and infra folk. For instance, let’s say you’re a platform engineer, and you want to update Postgres from V14 to V15. What wouldn’t be considered a “golden path” is when you ask your developers to do it manually and resource by resource. A golden path means you are updating it in one place and auto-enforcing a deployment to all dependent workloads.
I have dozens of examples of good golden path designs that I’d love to share with you. Join me on the 27th of June 2023 at 7 pm CET (12 pm CST), and I’ll take you on a journey where we’ll explore how to design them together.
Look forward to seeing you then!
Kaspar
