Photo by Diego Jimenez on Unsplash
Netflix uses it, so it should work great for you, right? Not so fast. The Paved Road is not for everyone. While it caters to the majority, there are always going to be developers who need (or choose) to go ‘off-road’. There are a few things you should consider before creating a Paved Road in your organisation. In this article I will discuss the pros and provide a few questions you should ask before implementing it.
In her 2017 OSCON presentation, Netflix’s Dianne Marsh describes the Paved Road as ‘A concept, formalizing a set of expectations and commitments between the centralized teams and our engineering customers’.
This means that a central team builds and (mostly) maintains the Paved Road for the benefit of its developer clients. In turn, developers who choose the Paved Road agree to comply with its philosophy. The result is that developers are free to focus on what they do best: building and delivering features. However, the Paved Road should not be siloed in that one team. Developers should not be discouraged to go ‘off-road’ occasionally to discover new horizons and to contribute back to the Paved Road.
That said, building a Paved Road can be a sizeable investment, and should be done in consultation with the teams intending to use it.
Figure 1: An example Paved Road workflow
Let us say you have several teams developing microservices that run on Kubernetes. Each microservice needs to have the same basic structure (service discovery, logging, etc.), so you create a template for each new service to be based on. Development teams are free to add any code behaviour they want, but the CI/CD pipelines must be the same for all. This could include building the code, testing, building images, scanning the images for vulnerabilities and, finally, publishing those images. All these processes are perfect candidates for the Paved Road and could be implemented in something like GitHub Actions. You can run code compliance checks, unit tests, and even test the Docker images as part of your pipeline.
Here are a few reasons to invest in a Paved Road solution.
So, you have decided you want to try your own Paved Road? Great! But there are a few questions you should ask before diving in.
First do a small feasibility study to determine this. Find out how easily the code can be built and tested. How much manual intervention is required? Does your organisation support automated processes like publishing images to a registry? If there are any blockers, you will first have to fix them; the Paved Road will not solve them for you.
Developers do not have the time to build it themselves. You need a team that is in contact with all teams so it can build the solution that best fits everyone. However, this team does not have to be 100% responsible for the continued maintenance of the Paved Road. As I mentioned earlier, developers are encouraged to go ‘off-road’ and explore, or even fix the occasional pothole. Developers should be encouraged to take an active interest and not overstuff the central team’s backlog.
This is down to your company’s culture. You may have some work to do getting alignment and buy-in before you can embark on this journey. And this does not just include development teams; the Paved Road weaves through multiple departments. For instance, it is in the CISO’s best interests to help set up the compliance and security tests to ensure the software being rolled out is as secure as possible, especially if you want continuous delivery.
The Paved Road is a great solution for standardising and managing compliance, but it is not suitable for everyone. And, like any solution, it needs proper care and maintenance. But, if implemented correctly, it can go a long way in making your developers’ lives easier.
For a concrete example of the Paved Road, as implemented at Ahold Delhaize, read Reinier Timmer’s blog post ‘A Paved Road for CI/CD using GitHub Actions’.