Backstage and Red Hat Developer Hub basics

Red Hat Developer Hub (Developer Hub) provides an enterprise-strength version of the open source project Backstage. Backstage is a project under the Cloud Native Computing Foundation (CNCF) designed to allow platform engineers to provide a fantastic single-point of access for developers into all of the tools and technologies they use, letting developers work without the cognitive overload that comes with software development today.

Developer Hub provides an out-of-the-box configured version of Backstage (Figure 1). This configured version comes with a number of critical plug-ins that make developing and distributing cloud native applications far simpler than it has been to date.

In order to understand what Developer Hub adds to the Backstage concept, we need to look at and understand what Backstage is and how it works. 

In this lesson, you will:

• Learn what Backstage is, what it does, and why it was made.
• Understand what Backstage templates and plug-ins are and their purpose.
• Discover which Red Hat-supported Backstage plug-ins are installed by default in Developer Hub.
• Learn how to add pointers to documentation and other resources via library objects.
• Discover Developer Hub's relationship to Red Hat OpenShift.

Backstage and Red Hat Developer Hub basics

Let's start with why you would want to use Backstage in the first place, as a platform engineer or administrator.

Why Backstage?

Let us tell you a little story. It's based on the truth, but like all good stories, some aspects have been changed for dramatic effect.

Once upon a time, in the late 2000s, a company created an extremely popular media platform.They developed their technology in the midst of an explosion of open source development tools, cloud architectures, and the DevOps and agile movements.

As its platform grew in popularity, so did its code, product offerings, and number of employees. Moving from startup to large scale enterprise—while exciting—came with the challenges of balancing the agility of developing features at scale with the absolute necessity to provide a stable, reliable, and rock-solid production platform.

Development teams had so many different tools, each with their own UIs. Many of these tools required support from a platform team, which added to their complexity. 

Onboarding, training, building out platforms, approving tooling, securing supply chains, evaluating, providing more and more platform services, autonomy of choice, new languages and frameworks, constantly expanding infrastructure needs, and a constantly expanding developer team—all of this led the startup from highly successful to crippled and lagging. The status quo no longer worked. Something needed to change.

They put their thinking caps on. What they needed was a self-service platform for developers all under one roof, through one access point. Where tooling choice was available as a catalog of options—all approved, all secured. Where different UIs from various developer tooling could be embedded into one window—one pane of glass, a portal—yes, an internal developer portal (IDP)!

But they took this one step further. Not just a portal with what is known today—but a platform that would allow the company to build future developer portals and expand as needed when new tooling was available. The company could even create templates of full application stacks as well as guardrails for development teams, help onboard new members, and give management confidence that everything being used in the enterprise software factory was safe, secure, and fit for purpose.

And they called it …. Backstage.

Why Red Hat Developer Hub?

Backstage is an open source project, built by Spotify to do what Spotify needed in the way Spotify wanted it. No enterprise features like support, lifecycle, certifications, testing, or bug fixing older versions.

Notwithstanding that Backstage is a framework to create an internal developer portal, customers need to create the portal and integrate the various plug-ins for the tooling they want their team to have access to. This is where Red Hat and Red Hat Developer Hub come in. We did what we do best, and turned Backstage into an enterprise-grade, internal Developer Hub with supported plug-ins for integration with Red Hat technologies.

What do platform engineers have to do with it?

While Developer Hub’s primary customer is an organization’s developers, it is a shared platform that is maintained and provided by the platform engineering team.

Backstage basics

Backstage acts as the serving point for a web-based developer and one-stop shop for all things development. It does this by serving a customized page to the end user, consisting of a standard left-panel navigation, right-panel content viewpoint. It maintains a set of object types that can be instantiated and used by the user, including components, APIs, documentation, and links. Backstage also provides an engine for processing something called a template. This template is a set of actions that are executed by Backstage, using injected parameters, and is limited only by what plug-ins are available to the system.

Plug-ins are where Backstage really shines. A plug-in provides external functionality to the Backstage engine, such as interacting with a GitHub repo, pushing objects to a Kubernetes or Red Hat OpenShift cluster, or interacting directly with Argo CD to provision controlled object sets to Kubernetes or OpenShift. These plug-ins give Backstage the raw functionality and infinite extensibility that make it such a powerful framework.

Plug-ins can also be used to provide further visualization components for the user interface (UI) served to the developer. 

In essence, Backstage acts as a plug-in orchestrator and an object state maintainer. Where Red Hat Developer Hub comes in and adds massive benefit is that it pre-installs a set of plug-ins. These plug-ins provide both visualization critical to developers and integration with next-generation, cloud-native development technologies and frameworks. 

Default plug-ins included in Red Hat Developer Hub

Out of the box, the initial release of Developer Hub installs specific plug-ins automatically, as shown in Figure 2.

The majority of plug-ins, with the exception of Keycloak, provide visualization content ported from the OpenShift platform itself. Notably the ability to visualize:

• The topology of an application deployed to OpenShift with the Application Topology for Kubernetes plug-in.
• Pipelines and pipeline execution with the Pipelines with Tekton plug-in.
• The contents of a container image registry with the Container Image Registry for Quay plug-in.
• The topology of a multi-cluster setup including application deployment with the Multicluster View with Open Cluster Manager plug-in.
• GitOps deployment with the GitOps with Argo CD plug-in. 

These plug-ins are automatically integrated into the UI that is delivered to the end user. When they interact with a target OpenShift cluster, they can visualize all of the components shown above just by clicking on a separate tab in their component view (Figure 3). 

This approach is critical because the developer now has all of the tools and visualization they need at their fingertips. Before the advent of Backstage and Developer Hub, in order to do all of the development tasks needed in the example above, the developer needed to log into at least three different systems. From there, they would probably have to extensively use Google search and keep a number of tabs open on their browser, all of which are a distraction.

Library objects send developers to key documentation

In addition to the plug-ins, both Backstage and Developer Hub provide mechanisms for giving developers direct access to critical documentation. Links to internal documentation, blogs, and articles can be added to the catalog, providing links directly from within the Developer Hub portal. All components added to the system are provided as YAML definitions that, given the appropriate permissions, can be added to the Developer Hub catalog. 

An example of this simple approach is shown below, a set of interesting blogs that are added as a catalog entry that can be viewed within the UI:

apiVersion: backstage.io/v1alpha1

kind: Component

metadata:

  name: uthblogs

  description: |

    Set of useful blogs

  links:

    - title: My First Neuron

      url: https://devepiphany.org/2022/05/24/my-first-neuron-atomic-ai-principles-fun/

    - title: KCP Overview

      url: https://devepiphany.org/2022/01/31/what-on-earth-is-kcp-and-why-should-i-be-very-very-excited-about-it/

    - title: Spark on OpenShift

      url: https://devepiphany.org/2021/05/19/spark-ly-openshift/

    - title: Kubernetes Introduction

      url: https://devepiphany.org/2021/01/15/interlude-kubernetes-koncepts/

  annotations:

    github.com/project-slug: utherp0/janustest1

    argocd/app-name: uthblogs

spec:

  type: library

  owner: Uther

  lifecycle: experimental

This piece of YAML, when added into the system via the UI, provides a library object that can be viewed by clicking on the resulting links. 

Next, you will learn how to access the Developer Sandbox for Red Hat OpenShift (Developer Sandbox), so you can install Red Hat Developer Hub.