This is an excerpt from Developer Portals: Prepare to Perform with Red Hat Developer Hub. Download the full e-book.

As a cultural initiative, DevOps has probably made software more reliable and its creation more rapid. Its best understood practices have benefited their progenitors, publicizers, and most successful adopters. Developer engagement with deployment concerns engenders a systems thinking that improves application architecture, but DevOps declares for developers an unbounded array of new concepts, terms, and concerns.

This increase in cognitive load can make it feel like the early returns from DevOps practices such as automation and “infrastructure as code” and its progression toward GitOps are diminishing and progress slowing. More than 80% of developers say they have some kind of DevOps responsibility. The more layers between code editor and cloud deployment a developer has to master, the harder it is to onboard new teammates and the greater the chances of their burning out in the face of endless switching into less and less familiar contexts.

The proliferating complexity of simple applications

Think about writing “Hello, World.” A few years ago, you’d grab your favorite editor or IDE, write some code, build it with your compiler or run it through your runtime. Then you’d hand it off to whoever controlled production when you pushed your locally-tested changes to the development branch. Your code got built and tested and deployed and had network traffic routed to it, backing services connected, deployment specifics configured, but little of that was within your control or even your line of sight.

DevOps implies a host of new concerns, systems, services, and tools.

Microservices add complexity along another axis. There are many pieces of any microservices application architecture. What is the component you need to work with in the first place? Who is responsible for a given microservice? How do you use its API facilities? What APIs and other components does it depend on? Where is its documentation?

Hello, [cruel] World

Writing “Hello, World” hasn’t gotten any harder. But running it has. Hello World today means a running container, built by an automated pipeline (triggered by a source code commit) into a container image, stored in some registry, with an attendant manifest declaring how it should be brought to life by a container orchestrator.

There is a lot of stuff that is not your application.

So much YAML

Build configuration, CI/CD, container, repository, Deployment, StatefulSet, Ingress, Route…

You want this stuff—or you should. And your company definitely wants it. It has a lot of benefits, even though we’re focusing on some of the drawbacks right now. But complexity in doing simple things will threaten to impose diminishing returns. In computing, the answer to complexity is always abstraction.

You’re supposed to be an expert in Java, Go, Python, or whatever your language and framework—not an expert on the details of your new team’s AWS and OpenShift environments, configurations, and prerequisites.

Trade it all for just a little more

Internal developer portals (IDPs) aim to provide abstraction of development processes, offering a surface for capturing a team’s tools, libraries, source boilerplate, and configuration and centralizing access to them. Ironically, in the IDP ecosystem examined here, simplifying all that YAML involves… a little more YAML.

Internal developer platforms

An internal developer portal is a set of tools, services, and practices intended to improve the productivity and collaboration of software development teams by abstracting and automating the surrounding complexity of the development and deployment process. An IDP provides developers with a unified environment for managing application components, services, and the development lifecycle, including code, infrastructure, and deployment.

IDPs address several key challenges in the software development process, including:

• Complexity: Modern software development involves many tools, services, and processes. IDPs centralize access to these resources.
• Collaboration: IDPs promote collaboration by offering shared resources, standardized workflows, and a consistent experience in a development team.
• Visibility: Developers can’t always see what other teams are working on. IDPs make large deployment environments more transparent.
• Productivity: By automating repetitive tasks and providing self-service capabilities, IDPs allow developers to focus on writing code and delivering value.

Backstage: A platform for building developer portals

Backstage is an open source IDP platform created by Spotify, originally to serve their internal development. Backstage organizes the developer portal around five central functions:

• Software Catalog: A central repository for the services and components used in a team or organization, enabling discovery and reuse. Catalog entities index the disparate resources that go into an application, from source code to build services to orchestrated deployments.
• Plug-in ecosystem: Backstage supports custom plug-ins and a growing ecosystem of integration and automation plug-ins. Plug-ins integrate Backstage with infrastructure services and software components, import patterns and mechanisms, and allow teams to customize Backstage to integrate their own systems, tools, and methods. 
• Standardized workflows: Software Templates are designed to capture effective patterns, tools, and processes used by development teams and present them as established paths to creating software. This helps make best practices and standards the easiest way to do things, too.
• Tech Docs conventionalize the mechanics of creating and publishing documentation but someone still has to write it. You can write documentation easily in Markdown or other familiar markups and manage it like code in your repos to see it compiled and published in an automated way.
• Search lets others find components, services, and documentation without clicking around endlessly.

Backstage aims to enhance developer productivity with a single place for development activities.

Backstage history

Backstage started at Spotify in 2016-17. Spotify developers maintain a huge number of microservices, components, and tools.

Backstage addressed the complexity and obscurity attendant in an ever-expanding set of services and tools—and ever-expanding teams creating and using them. The main idea was a unified interface for discovering and interacting with all of the resources that comprise an application. Not just source code, but integration and deployment configuration, source control, standard versions, languages, and libraries; execution status; rebuild and redeploy automations—everything. Even docs.

In 2020, Spotify released Backstage under the open source Apache license, allowing other organizations to use the platform and contribute to its improvement. Developers and companies adopted the project in response, many of them, including Red Hat, contributing new features, abilities, and fixes to the upstream code base. A Backstage ecosystem has grown around the core software as well, with plug-ins and integrations developed to extend its functionality.

In 2022, the Cloud Native Computing Foundation (CNCF) accepted Backstage as an incubating project. This solidified Backstage's position as a principal implementation of IDP concepts and standardized the project’s governance within the CNCF landscape.

Learn more: Unveiling Backstage: A developer's guide to the CNCF project

Backstage today: Project and ecosystem

Backstage is an open source platform designed as the foundation of an internal developer portal. Earlier, you saw the three key software expressions of Backstage’s purpose. Those features are how Backstage abstracts complexity and provides paved roads to standard tools and practices. When resources are documented, discoverable, searchable, and their dependencies and ownership clear, teams benefit in several ways.

Backstage promotes collaboration by providing visibility into what different teams are working on. Transparency helps prevent duplication of efforts, encourages reuse of services and components, and fosters a sense of community among development teams.

Backstage can automate tasks such as creating new services or components, provisioning infrastructure, and generating documentation. Automation reduces manual overhead and lets developers focus on writing code.

Teams can customize Backstage with features and plug-ins to fit their specific requirements. Since Backstage has a growing community of contributors and adopters, new features, integrations, and improvements appear frequently.

Red Hat Developer Hub      

Akin to familiar Red Hat flagship products like Red Hat Enterprise Linux and Red Hat OpenShift, Red Hat Developer Hub (RHDH) is an enterprise distribution with an open source project at its core. RHDH harnesses the Backstage core code together with enterprise features, curated plug-ins, and day-two configuration for common development scenarios.

Like Backstage, Red Hat Developer Hub is a platform for building developer portals. There is always platform engineering work, with or without that formal title. Identifying patterns and standards and refining them in line with organization goals is a key part of getting value out of your site’s developer portal. RHDH makes it easier for you to get started with the examples in the book by avoiding a lot of secondary decisions about integrations, configuration, and features that you’d need to make if you started from scratch with upstream Backstage.

Summary

Every team and every project evolves a tailored development environment. This collection of tools, services and configuration is often maintained by convention and transmitted by osmosis.

Internal developer portals help teams curate, manage and replicate these environments. Backstage is an open source CNCF project for building developer portals, and for encapsulating tools, services, documentation and best practices in “golden paths” to ease onboarding and everyday work. Red Hat Developer Hub is Red Hat’s enterprise IDP, curating Backstage core and the ecosystem around it.

Download the full e-book: Developer Portals: Prepare to Perform with Red Hat Developer Hub