Internal Developer Platforms (IDP) are a semi-emerging idea, although it’s hard to quite say that they are “emerging” because it’s something that engineers have been building for years. The concept isn’t new, it just has a name to it now.
In parts 1-3 of the Platform Engineering On Kubernetes series, you dove into the ability to use Kubernetes as the platform of choice with Kubernetes-specific tooling. In part 4 (which is the final part of this series), you’ll see how to use an IDP to make deploying workloads to Kubernetes far easier and more efficient for everyone who isn’t a Kubernetes expert.
Prerequisites
To follow along with the hands-on portion of this blog post, you will need:
- A Linux virtual machine (it can be running anywhere). This is for the Backstage hands-on portion.
- A Kubernetes cluster
If you don’t have these, that’s fine. You can still read through the hands-on portion to get an idea of what you’ll need from a hands-on perspective.
Why IDP’s
For quite a while at this point in tech history, there have been key engineers at organizations who would focus on making other engineer’s lives easier. Whether that was through automated processes, building easy-to-use UI’s for complex tools, or simply making some API calls with one script that would rule out all of the complexity for a developer or engineer.
Internal Developer Platforms aim to remove the need to be an expert on the platform you’re deploying to.
Taking Kubernetes as an example, let’s talk about Deployments. If you want to deploy, scale, and manage a Kubernetes Deployment that has one or more Pods, there’s a fair amount you need to know. How the Kubernetes API works, API groups, the full spec, YAML, and how it’s deployed. In short, it’s not a trivial task.
What an IDP could do in this case is give you a UI where you essentially fill in some info (container image, version, ports, commands, etc.), click a button, and just like that the Kubernetes Deployment is deployed. You don’t have to be a Kubernetes expert. The experts already configured the IDP and tasks to work in this fashion. You just have to deploy.
An IDP is all about removing as much complexity as possible, making logical abstractions on top of the complexity, and having that complexity managed by key engineers (Platform Engineers) in an organization.
Backstage and Port
The two methods of setting up an IDP are:
- Create your own.
- Use a product that already exists for this purpose.
There are several engineers who have created their own form of an IDP (myself included) years ago, and it’s still a fun, exciting, and great engineering practice if you have the engineering power/headcount to do so. However, there is power in the phrase “don’t re-invent the wheel” when it comes to IDP’s. In today’s Platform Engineering world, there are two primary IDP’s – Backstage and Port.
Backstage was originally designed and built at Spotify and then donated to the CNCF.
Port is a software company that’s been around for a little under two years and has a pretty large backing from a financial perspective.
Both tools/products do very similar things but go about it in a slightly different way. For example, Backstage is something that you fully manage yourself (install, configure, update, etc.). Port is SaaS, so it’s fully managed for you.
In the next section, you’ll dive into configuring both.
Configuring Backstage and Port
Now that you have some theory and understanding behind the whole idea of IDP’s, it’s time to dive into them from a hands-on perspective.
In the upcoming sections, you’ll configure both Backstage and Port.
Installation Issues PLEASE READ
If you’re installing Nodejs on Ubuntu, you may run into an issue where you see an error message that looks something like the one below.
If it’s not something like this, it may be another error that shows something about a function not existing.
If that’s the case, despite the lack of error messages available, it may be due to the Nodejs version (at least it was for me).
Ubuntu, by default, using apt, will install version 1.12.x. Backstage requires a minimum of v1.14.x, which means you’ll have the pull the binary and install it outside of Aptitude (Ubuntu’s package manager).
To ensure that you install a Nodejs version compatible with Backstage, run the following.
curl -sL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install nodejs
This will update the package manager on your server to use v1.18 of Nodejs.
Update the system packages.
sudo apt-get update
Install Yarn.
npm install --global yarn
Backstage Installation
The overall install process for Backstage is a bit hefty. Outside of needing a VM, you also need:
- NPM (JavaScript package manager)
- Yarn (handle project dependencies for Node)
- Docker
- Git
Once the prerequisites are installed, you’ll need to use the NPM Backstage package to create the Backstage app.
To do that, run the following.
npx @backstage/create-app
You’ll then be prompted to give your Backstage app a name. In this case, you can choose whatever you’d like. Something like “k8sbackstage”.
Once the installation is complete, you should see an output similar to the screenshot below.
You’ll also see a new directory named the name that you gave the app.
💡 IF THE INSTALLATION FAILS for Yarn, it may be due to dependencies missing. cd into the directory where the app exists and run yarn. You’ll see that all of the dependencies begin to download.
cd into the new directory.
cd k8sbackstage
If you plan to access the Backstage server outside of localhost:3000, you’ll need to change the app-config.yaml. Run the following:
sudo vim app-config.yaml
Update the baseUrl and the cors origin to reflect the IP address of the server.
Once complete, use Yarn to handle all of the dependencies for Backstage and run Backstage.
yarn dev
You should see an output similar to the one below.
In a web browser, open up http://localhost:3000/ (or your VMs IP address if you updated the app-config.yaml file) and you should see an output similar to the one below.
Port
Go to the following URL: https://www.getport.io/try-now and click the Sign up button under the free account.
Once you’re signed up, the first screen you’ll see are methods around what your current environment looks like. Choose the Kubernetes ecosystem option.
Click the blue Get this template button.
Run the following script in your Kubernetes cluster to connect the cluster to Port.
You’ll now see your Kubernetes cluster in Port.
Once the Port instance is up and your Kubernetes cluster is configured on Port, you can start using its features.
There’s a lot that can go into it, so instead of posting several screenshots, you can take a look at the configuration docs found here: https://docs.getport.io/.
Backstage or Port?
Both tools are great, serve a particular purpose, work well, and make the process of delivering software faster. After configuring both, speaking with other engineers, and seeing the ecosystem as a whole, at this time it seems that Port is a more effective method of delivering an IDP, unless you want to manage the IDP from infrastructure to creation to management yourself and remove the SaaS component.