{"id":4708,"date":"2025-08-01T21:58:33","date_gmt":"2025-08-01T19:58:33","guid":{"rendered":"https:\/\/gokhan-gokalp.com\/?p=4708"},"modified":"2025-08-01T21:58:33","modified_gmt":"2025-08-01T19:58:33","slug":"devex-series-01-creating-golden-paths-with-backstage-developer-self-service-without-losing-control","status":"publish","type":"post","link":"https:\/\/gokhan-gokalp.com\/tr\/devex-series-01-creating-golden-paths-with-backstage-developer-self-service-without-losing-control\/","title":{"rendered":"DevEx Series 01: Creating Golden Paths with Backstage, Developer Self-Service Without Losing Control"},"content":{"rendered":"

As an architect involved in platform engineering and DevEx<\/em> transformation within a large-scale organization for the past few years, I\u2019ve seen firsthand how developer experience directly shapes not just the speed and quality of software delivery, but also how effectively teams can adopt governance<\/strong>, security<\/strong>, and compliance<\/strong> practices as enablers rather than blockers. I can truly say this was made possible by establishing proven golden paths<\/strong> and enabling true developer self-service<\/strong>.<\/p>\n

In this first post, I will try to explain how we can use Backstage<\/strong><\/em> to create these golden paths. Predefined, opinionated software templates that help developers spin up new services quickly and stay compliant without added friction.<\/p>\n

Before diving deeper, it’s worth clarifying first what we mean by platform engineering and DevEx.<\/em><\/p>\n

What Do We Mean by Platform Engineering, DevEx and IDPs?<\/h1>\n

\"\"<\/a><\/p>\n

Platform Engineering<\/strong><\/h2>\n

I can say, it is the discipline of building and maintaining the internal infrastructure, tooling, and workflows that empower development teams and enable self-service capabilities. It\u2019s like providing a paved road for developers to drive on. It creates kind an abstraction layer between developers and operations that not only shields developers from unnecessary complexity but also ensures that operational, security, and compliance concerns are handled by design.<\/p>\n

Why Did Platform Engineering Emerge?<\/h3>\n

In my experience, as organizations scale their engineering teams and adopt cloud-native architectures, development teams face growing friction. They spend increasing amounts of time setting up infrastructure, understanding CI\/CD<\/em> pipelines, managing permissions, complying with security policies and often reinventing the wheel in slightly different ways.<\/p>\n

While DevOps<\/em> also is meant to bridge the gap between development and operations, in practice it often shifts more operational responsibilities onto developers without providing the right tools or abstractions. Today, with new tools popping up constantly, things have become even more complex. The usual result is cognitive overload, inconsistent practices, and slower delivery.<\/p>\n

In contrast, platform engineering brings a product mindset<\/strong> to internal infrastructure. It focuses on building reusable, self-service platforms that abstract away complexity while enforcing standards.<\/p>\n

These platforms are often referred to as Internal Developer Platforms<\/strong><\/em> (IDPs<\/em>), and are designed to give developers everything they need to build, deploy, and operate software efficiently and securely. You can think of an IDP<\/em> as something like ServiceNow<\/em>, but built specifically for developers. Just as ServiceNow<\/em> provides a centralized place for business users to request IT<\/em> services, an IDP<\/em> provides a unified interface where developers can access templates, provision infrastructure, set up CI\/CD<\/em>, or request resources all in a consistent and compliant way.<\/p>\n

While it is possible to build your own centralized platform automation control plane, for example, you might use tools like Crossplane<\/em>, Tofu Controller,\u00a0Argo CD<\/em>\u00a0and OPA<\/em> on top of k8s<\/em> to make that happen, of course depending on your IaC<\/em> and GitOps<\/em> strategy, there are also mature tools and reference architectures available that are worth exploring. You can take a look at some of them here<\/a><\/em>.<\/p>\n

Developer Experience (DevEx)<\/strong><\/h2>\n

DevEx<\/em> refers to the overall experience developers have throughout the software development lifecycle. It includes everything from how quickly developers can start a new project to how easily they can locate documentation, access infrastructure and tooling, and troubleshoot problems. It\u2019s about removing friction at every step, giving clear paths<\/strong>, fast feedback loops<\/strong>, and removing unnecessary toil<\/strong>.<\/p>\n

Good DevEx<\/em> means developers spend less time on repetitive, low value tasks and more time solving real business problems and driving innovation. It reduces frustration and boosts productivity, all while improving consistency<\/strong> and compliance<\/strong> across environments.<\/p>\n

When we invest in DevEx<\/em>, we are not just improving developer happiness. We are increasing productivity, quality, and engagement. That in turn, directly impacts an organization\u2019s ability to move faster, respond to market demands, and create more room for innovation.<\/p>\n

In short, while DevEx<\/em> is about the overall experience, IDPs<\/em> and Developer Portals<\/em> (DevEx Portals<\/em>) are how we can bring that experience to life. The platform provides the underlying capabilities, the engine, enabling things like self-service infrastructure provisioning, CI\/CD<\/em> pipelines and policy enforcement in standardized and secure way. The portal is the UI<\/em> for these platform capabilities, a single pane of glass where developers can access everything they need from templates and docs to services, APIs<\/em> and observability tools.<\/p>\n

In my experience, platform engineering plays an important role in shaping DevEx<\/em> by providing the paved paths, guardrails and tools developers need to move fast and safely. When done right, it enables teams to ship confidently without sacrificing standards or autonomy.<\/p>\n

Also, one thing I have observed is that when some people talk about improving DevEx<\/em>, the conversation often jumps straight to infrastructure layers, IDPs<\/em>, or complex automation frameworks. While those are undoubtedly powerful and lay the foundation, in my view and based on my experience, they are not always the most accessible<\/strong> or practical<\/strong> starting point, especially for teams that aren\u2019t yet ready for full platform engineering efforts.<\/p>\n

In my view, I might be also wrong, you can begin your DevEx<\/em> journey by bringing standardization, documentation, and discoverability to your existing software assets. This is where tools like Backstage<\/em> (a DevEx Portal<\/em>) come in.<\/p>\n

Backstage<\/em> helps teams create golden paths <\/strong>that are\u00a0well-defined, reusable<\/strong> templates and documentation that guide developers through consistent ways of building software. It offers a central DevEx Portal<\/em>, or single pane of glass, where developers can find everything they need, from APIs<\/em> and services to documentation and CI\/CD<\/em> status, without jumping between tools. As the organization matures, it also allows seamless integration with broader platform capabilities, including the IDP<\/em>.<\/p>\n

So, with that being said, let\u2019s dive into Backstage<\/em> and see how it can help us create golden paths and improve DevEx<\/em> from day one<\/strong>.<\/p>\n

Backstage: The DevEx Portal<\/h2>\n

Backstage<\/em> is an open-source DevEx Portal<\/em>\u00a0originally created by Spotify. <\/em>It enables organizations to centralize and standardize how software assets, developer workflows, infrastructure components, and tools are managed. By bringing everything into a single, self-service interface, Backstage<\/em> helps reduce context switching, promote consistency, and improve developer productivity at scale.<\/p>\n

And that really matters<\/h3>\n

Because if you think about the typical developer’s day, it’s filled with small but constant interruptions such as:<\/p>\n