Reading a lot about platform engineering kept reminding me about the concept of the paved road (I’ve also seen the term “golden path”) in software engineering. It’s easy to understand why – if you do platform engineering correctly, then you end up with a paved road. Spotify probably has the best definition of a golden path (emphasis mine): “The Golden Path — as we define it today — is the ‘opinionated and supported’ path to ‘build something’ (for example, build a backend service, put up a website, create a data pipeline).” For all practical intents and purposes, a paved road is essentially the output of platform engineering. But why should we be trying to pave these roads? Shouldn’t we just build a stack and incorporate toolsets specific to each project, app, or service? Surely that way we can optimize for the specific problems each was built to solve, right? Wrong.
There’s a lot more that goes into deploying and running software than just the application code – there’s security, observability, metrics, and infrastructure (that’s code now, remember?). A paved road is designed to incorporate all of that for you so that by the time you initialize your project you have everything you need to run your code somewhere besides your machine, with minimal extra work for you. If you’re running your code in containers, those Dockerfiles are built from a base image that has any libraries needed, exposes standard (for your company) ports, and is kept up-to-date. If you’re deploying via Terraform, that’s a set of modules that fit common architectual patterns that you know are secure, scale well, and are easy to run.
Paved roads also keep things consistent across code bases, which is phenomenal for teams managing multiple applications and services. Consistency across the different code bases you have to maintain vastly reduces the cognitive load when switching between them. It’s also a big benefit when onboarding new developers – because applications and services are all built the same way, once you get your local environment set up to run 1 application, you’re basically set up to run the rest of them.
Paved roads are like a good framework – they take care of a lot of the standard boilerplate stuff that you need to have so you can focus on the specific problem you started writing code to solve. The main reason that platform engineering is getting so hyped up these days is because they deliver a paved road to developers. You don’t have to try to remember how you instrumented something on some other project because that worked really well and it’s worth bringing in here – you’ll have it if you just follow the golden (brick) path. Just use it and get straight to the problem at hand. Trying to figure out how to architect a new service? The paved road can lead you in the right direction.
The biggest benefit to having paved road architecture is the support. If you follow the paved road, that is a known good architecture, and it will just work. If it doesn’t, then the team who built are committed to working with you to get it running. Knowing that following the paved road means that you’re going to have support encourages you to bias your decision-making towards existing expertise and defined best practices. The fact that going off the paved road means you’re going on your own pushes developers to either make sure they understand exactly what they’re doing before abandoning something they know works, or be in a position to embrace experimentation with a specific project.
An important thing to remember about paved roads is that they aren’t requirements that must be followed no matter what. The flip side to the paved road contract is that while the paved road provides a supported set of tools that is that you can always leave the paved road to make your own dirt trail on your own. As I mentioned earlier, there’s a good bit of pressure to not do that, but if you’re certain the paved road can’t solve your problem, that’s fine – it’s just that you’re going to need to pave your own trail.
Paved roads are a valuable resource for software engineering teams. They take a lot of time to build, but if you’re willing to put in the time to take best practices, bundle them up and offer them up in a pre-packaged format, they solve a lot of development problems at the very beginning of new development. Because they’re presented as usable solutions, paved roads make it as easy as possible to follow best practices and integrate tooling into your applications and services. They’re what make platform engineering so valuable, and if you can start the process of building them, they’re going to be worth it to you. Any type of best practice, useful tooling, good configuration, clean architecture – if you can find a way to make it easy for developers everywhere to do or use it, you’ll find it makes everyone’s lives easier.