Using an Internal Developer Portal for Golden Paths
Developers feel constrained because they want to move quickly, releasing as many features as possible. But the platform team needs to ensure that whatever developers do adheres to engineering standards and doesn’t put the company at risk.
DevOps leaders often worry that developers may not fully understand how to comply with these standards or grasp the infrastructure they’re working with. To alleviate those concerns, they could require developers to request access to services or systems through ticket ops, or simply by asking DevOps directly.
This is where golden paths come in. They strike a balance between granting developers complete freedom and requiring DevOps to handle everything to avoid potential mistakes by developers.
Chad Metcalf from Daytona described a golden path as an “opinionated and supported path to build and run systems.” He explained that it “provides recommended tools, processes, and documentation tailored for developers within an organization.”
Metcalf emphasized that paved roads impose fewer constraints on developers. This is music to developers’ ears.
Golden paths also necessitate a mindset shift, with a growing emphasis on developer experience (DevEx) in the platform engineering space. Platform engineers aim to provide developers with a better experience, and golden paths are seen as a way forward. While many organizations focus on creating the golden path, staying on this path is an effort that should be equally considered.
How Does It Work?
Golden paths enable developers to accomplish tasks independently while ensuring platform engineers and DevOps have embedded the organization’s standards. Practically, this involves providing automation or self-service options, allowing developers to quickly perform tasks with the right guardrails in place. This approach often reduces the cognitive load on developers since they don’t have to choose one of multiple options to complete an action; they simply follow the golden path.
However, even when developers adhere to golden paths, it’s crucial to ensure that standards are maintained over time and not degraded after the initial self-service action. A golden path only remains effective if developers continue to follow it. Golden paths are a life cycle rather than a one-off task. One way to achieve this is by adopting a product mindset, ensuring that everything is built with the developer in mind.
How Golden Paths Can Help Developers
- Reducing cognitive load: The constant influx of new development tools and technologies makes it impossible for developers to keep up. Even highly skilled developers with experience in tools like Terraform or those who understand the infrastructure may struggle even if they are full-stack developers. Golden paths allow developers to complete tasks without in-depth knowledge of each tool or infrastructure, reducing cognitive load and frustration.
- Increasing velocity: If developers have to wait three days for a Kubernetes cluster or a database cluster to be provisioned, that’s wasted time. If they can deploy these clusters themselves with a click of a button and have them ready in 5 or 10 minutes, their velocity increases significantly.
A Golden Path Life Cycle
There are three key steps you need to consider when building golden paths:
- Stepping into the path: Self-service actions that meet standards
- Checking if we are staying on that path: Measuring existing resources based on our standards
- Bringing the “bad” resources back to the path: Addressing noncompliant resources
Self-Service Actions That Meet Standards
A prime example of a golden path is offering developers standardized automation for managing applications, cloud resources and other organizational assets. For instance, when creating a new Kubernetes cluster, the process would include predefined security and networking standards, as well as version control, through a self-service action. This allows developers to quickly create the cluster while ensuring compliance with established standards.
In the case of creating a new AWS RDS cluster, many organizations have automated processes for this (or for creating other cloud resources). Typically, this involves connecting to the Terraform environment via GitHub, updating a git repository and applying changes after a pull request. The objective is to streamline this process while ensuring adherence to security, production readiness, availability and version standards from Day 1.
Maintaining Standards: Scorecards for Existing Resources
The next step involves monitoring the standards of your existing resources. For example, can you track if someone with admin permissions has changed the version or security settings? While some organizations perform these reviews manually on a quarterly or monthly basis, a more efficient approach is to automate the process.
In the AWS RDS cluster example, you must be able to identify clusters that are approaching end of life or lack high availability at any given time. For instance, a database with only one replica instead of three is not highly available, creating a single point of failure in the architecture. This can be assessed using a “scorecard” approach, which scores the level of standards compliance.
Addressing Noncompliant Resources
If a resource is found to be noncompliant, such as a database with an incorrect version or Kubernetes workloads with insufficient replica counts, it is crucial to have a method for developers to correct these issues and return to the golden path. This ensures all resources remain aligned with the organization’s standards.
Implementing Golden Paths Using an Internal Developer Portal
Let’s explore how golden paths are implemented in an internal developer portal, focusing on three key pillars: the software catalog, self-service actions and scorecards.
Step 1. Establishing the Software Catalog
Developers should feel comfortable in the portal, easily finding and accessing the information they need. This is where the software catalog comes in. It serves as an inventory of all the assets in your organization, including a service catalog, cloud resources, Jira boards and more. It encompasses everything relevant to the developers’ routine, providing a comprehensive overview and easy access to necessary resources.
The service catalog serves as the developer’s landing page within the portal. Here, they can view all their applications in one place, with relevant details such as the application name, the owning team, the git repository URL and more. They can also access information pertinent to their daily routines, like data from AWS (whether it’s RDS clusters or Lambdas running S3 buckets) and updates from their team’s Jira board, all filtered for their needs. The goal is to visualize everything necessary for their daily work, with live integrations from various tools.
Developers can see different clusters when they click on the RDS Clusters view.
Step 2. Create Self-Service Actions
When a developer is working on a new microservice, they likely need a database. Ideally, they can use self-service actions in the portal, where a form allows them to create what they need. This self-service capability is defined and provided by the platform team.
For example, by clicking on the top-right button labeled “+ RDS Cluster,” the developer can create a new RDS cluster.
The design of this self-service form uses abstraction. The developer provides simple, relevant inputs for the creation of the new RDS cluster without needing specific knowledge about the AWS resource or the infrastructure. The platform engineers have preconfigured these forms with dynamic parameters. By using the self-service form, the developer follows a golden path set by the platform engineers and DevOps teams.
The developer can then see logs reflecting the action: A new RDS cluster is being created and subsequently created successfully. This process is enabled by connecting the portal to a GitHub action that updates the Terraform file and provisions the cluster for the developer. This method meets the platform team’s standards and is efficient, taking only a minute. The developer doesn’t need direct access to the AWS console, though they can access the console if they want to. Instead, they can find all the necessary information in the catalog. They can click on the newly created resource:
Here, the developer finds all relevant details, such as the Amazon Resource Name (ARN), the engine and a link to their AWS resource. The new core resource added to the software catalog shows the link, version and comprehensive information about it, making the portal a single source of truth for the environment.
Step 3. Scorecards
The next step is to show how developers can continually measure their resources through scorecards.
This involves creating rules to assess the quality of assets in your software catalog. The portal allows you to define organizational standards and what each resource should be measured against. This is carried out via a scorecard — a metric created on top of the portal’s data to answer questions like, “Is my DB nearing end of life?” or “Does my DB have high availability?”
By clicking on the scorecards tab within the new resource, developers see a screen dedicated to them. For example, there might be two scopes to measure: production readiness and version.
There are three tiers: bronze, silver and gold. In this example, “gold” represents a perfect database, while a database not meeting the requirements is labeled “basic.”
The scorecard measures various aspects to ensure the new cluster is up to date and that the self-service action in place is also current.
To ensure production readiness, the scorecard checks whether the database runs in multiple availability zones, has deletion protection configured, and has backups and performance insights set up by AWS. All KPIs and standards for scorecards are fully customizable.
Step 4. Day-2 Self-Service Actions
Measuring your resources is a great start, but being able to proactively upgrade and fix your resources when they are not on track is just as important. If you can’t ensure that your resources return to the golden path, then the measurements are useless. So Day-2 self-service actions enable you to realign the resources that no longer comply with your standards. For example, using the “version” scorecard, it is possible to notice that some RDS clusters are out of date. Therefore, for every RDS cluster in the software catalog, you can provide a Day-2 action for upgrading the out-of-date cluster. A developer can view all the resources that they own that are not complying with standards at any given moment on the portal’s homepage. They can then click a link directly from the homepage that enables them to upgrade these resources using the self-service action.
Golden Path Life Cycle
In this example, the golden path isn’t just about creating a new resource; it includes the basic questions preconfigured by platform engineers, ensuring standards are built in, processes are seamless and communication between engineers and developers remains positive. Additionally, using the portal helps organizations establish and maintain the golden path, ensuring that developers stay on the golden path life cycle at every step. This continuity is crucial for success.
Watch the webinar on golden paths here.
Learn more about internal developer portals, platform engineering and DevEx at the virtual event Portal Talks on Jun. 26-27, 2024. The New Stack’s Jennifer Riggins will be hosting.
