Platform Engineering & IDP Quickstart: Deploying Backstage

Engineers and technical leadership teams have three common goals:

1. Increase efficiency.
2. Reduce toil and effort on teams.
3. Build better abstractions.

Perhaps most importantly, number 3. Abstractions for everyone who needs to perform a particular job, but may not need to know what's going on underneath the hood.

In this blog post, you'll learn about one of the most effective ways to accomplish all three - by using IDPs.

Platform Engineering Recap

Organizations want to “do the Kubernetes thing” because it’s the de facto standard across the industry. At the same time, technical leadership teams do not want to:

1. Hire engineers who are just Kubernetes experts
2. Spend time with a massive amount of training for engineers to get up to speed.

And the majority of engineers don't need to know what's going on underneath the hood. If Kubernetes is running the platform/application that they're working with, they don't need to be Kubernetes ninjas.

Technical leadership teams want to use Kubernetes without the overhead. Engineers want the promise of Kubernetes (high scalability, self-healing, performance optimization) without the overhead of becoming experts in the orchestration layer. That “overhead” (the Developer Experience and Kubernetes being difficult) is the primary business motivator behind Platform Engineering.

Platform Engineering is a combination of having a product-first mindset, a customer service mindset, and the engineering abilities to implement the idea. The idea that Platform Engineers are implementing typically involve the job of making the lives of whoever is using the platform easier.

Why IDPs

Internal Developer Platforms/Internal Developer Portals (IDP) is the platform/tool/application that sits on top of Kubernetes.

The idea of an IDP is that it gives engineers USING the tools an easier way to interact with them. For example, let's say your organization has decided on ArgoCD for the GitOps solution. Instead of having to know the ins and outs of ArgoCD, you can just access ArgoCD via the IDP. What's exposed to you via the IDP is only what you need to get the job done.

At the time of writing this, the two most popular IDPs are:

1. Port
2. Backstage

For those who want a more enterprise solution, use Port. If you want something that's highly customizable, can be built to your liking, and is open-source, use Backstage. Both are great options, just with different purposes/audience.

Now that we know a bit about IDPs, let's learn how to deploy Backstage.

Deploying Backstage

The first step to getting Backstage deployed is ensuring that you have the correct Node version. At the time of writing this, there is a dependency on Node version 18 for running Backstage.

To install Node v18 on Ubuntu:

sudo apt install nodejs

To install Node v18 on Mac:

brew install node@18

To install Node v18 on Windows:

choco install nodejs --version=18.11.0

Once Node is installed, you can use NPM/NPX, which is Nodes package manager to create the Backstage deployment locally.

npx @backstage/create-app

You'll be asked to give it a name. For the purposes of following along within this blog post, you can name it k8sbackstage.

The output you see on your terminal is for configuring the application (in this case, the application is Backstage).

Once complete, you'll see that the k8sbackstage directory contains all of the application's needs to run Backstage.

Running Backstage

To run Backstage locally, you'll use yarn, which is (yet another) package manager for JS projects.

There are two ways you can run the project:

1. yarn dev
2. yarn start

The purpose of yarn dev is to run a development server for testing purposes. yarn start is for production purposes.

Run the following command:

yarn start

You should see an output on the terminal similar to the one below.

You'll also see a webpage automatically pop up in your browser.