What are golden paths?
In the context of platform engineering, golden path refers to a way to do things that is tried and tested, templated and approved.
The original authors of the concept call golden paths an “‘opinionated and supported’ path to ‘build something’ (for example, build a backend service, put up a website, create a data pipeline).”
As such, golden paths are a set of tools and processes which are the recommended way for doing something, as defined and documented by the platform engineering team. They are supposed to help software engineers solve their daily problems and make their daily work easier, which is the core purpose of platform engineering.
Golden paths were born out of the realisation that the requirements of software engineers are diverse and platform engineering teams cannot possibly cater to every niche use case that may arise. So, instead of solving every problem that software engineers may have, the idea was born that platform engineering teams instead provide “golden paths”, which engineers can choose to use as-is, or can choose to adapt to their own needs.
Golden paths are a collection of documentation, tools, and processes for doing something which also offer the option for individual engineers to diverge from the golden path and e.g. modify provided templates to suit their own needs. In this way, platform engineering teams provide working solutions that serve as best-practice examples, cater to the needs of the majority, but still allow individual engineers or teams to build their own solutions when needed. They also serve to clearly delineate responsibilities: Platform engineering teams support the golden path, but if an engineer chooses to go “off road”, she is on her own.
Golden paths are intended to be:
- A best practice implementation
- Suitable for the majority of software engineers
- Supported, meaning that software engineers that struggle with using a golden path can expect help from their platform engineering team,
- Adaptable, meaning that individual engineers are allowed and should be provided with the tools to diverge from the golden path.
Where does the name golden path come from?
The concept of the golden path was coined at Spotify, one of the earliest champions of platform engineering. As this Spotify blog post describes, the term was probably inspired by the science fiction epos “Dune” by Frank Herbert. In the third book of the Dune series (Children of Dune), the protagonist has diverging visions of the future. In all but one of his visions of the future, humanity becomes extinct. There is only one future where humanity survives. The protagonist calls the path to this future the “golden path” and dedicates his life to ensuring that humanity stays on this “golden path”.
The analogy is not perfect: Golden paths in platform engineering are supposed to be open. Diverging from the golden path is not expected to lead to horrible outcomes, but should rather be seen as a productive way for software engineers to solve their own problems.
When I first heard of the concept of golden paths, I thought of the yellow brick road from “The Wizard of Oz” by L. Frank Baum. That children’s book starts with a storm that blows the protagonist, a little girl, to somewhere far away from home. She decides to follow a yellow brick road, which leads her to some adventures that eventually bring her back home. In this story, the yellow brick road is equivalent to the safe path that delivers the protagonist to her destination.
Conclusion
Whatever the literary inspiration for the term “golden path” really was, the core concept behind it is a hugely useful one. It takes the idea of self-service to another level. It allows engineers to not just use tools in self-service, but to build tools or adjust tools in self-service, and to do so with clear delineations of responsibility.
This idea of providing developers with a golden path that is discoverable and adaptable is the basis on which we built Cloudomation DevStack, our platform for cloud development environments (CDEs). We designed it in a way that makes it easy for platform engineers to template what a CDE looks like, and for software engineers to discover these templates in self-service, allowing for several points of entry where software developers can diverge from the golden path in a modular way.
If you’re interested to learn more, I’m always curious to hear your thoughts and share mine. Drop me a line on LinkedIn or via email.
