Michael LevanWhen the idea of Platform Engineering began to get on every engineer's radar, another term popped up at just about the same time - IDP. The big question is “How do these two work together?”.
Although Platform Engineering isn’t strictly about IDPs, IDPs do play a big role in the realm of Platform Engineering and it’s good for every engineer in a technical job to learn and understand. Management and leadership can even get a lot out of knowing IDPs.
In this blog post, you’ll learn what an IDP is and an example of how to use one with a popular IDP tool called Port.
Prerequisites
To follow along with this blog post in a hands-on fashion, you will need:
- A GitHub account
- Experience with CICD
- A Port account. You can sign up for free here.
What’s An IDP?
IDP stands for Internal Developer Platform.
💡
IDP has the word “Developer” in it, but remember, IDPs aren’t just for Software Engineers. Any type of tech person can get use out of an IDP.
An IDP in a nutshell gives the engineer that’s using it the ability to work with tools and platforms in an easier way because of the abstraction. For example, there could be a button that you click and a Kubernetes cluster gets created.
There are two audiences for an IDP:
- The engineer creating the IDP or building on an existing IDP (typically a Platform Engineer).
- The engineer/developer using/consuming the IDP.
First, let’s talk about the engineer who’s creating/building upon an IDP. These are the engineers who are as close to an expert as possible in the underlying platform and it’s capabilities. The goal here is to build services to abstract away complex tooling. For example, let’s say developers/engineers using the platform need a GitOps solution. The job of the Platform Engineer would be to build an abstraction on top of a GitOps solution and provide a way to interact with the GitOps solution (like a button or a CLI). The engineer/developer using the platform has zero idea what GitOps solution it is, how it works, or how it was built. They just know how to use it in an abstraction fashion via the platform that’s built for them.
On the flipside, the engineer/developer using the IDP has no idea how it’s built. They aren’t managing the underlying platform, where the IDP runs, how it runs, or anything in regards to the platform. They’re users of the platform. They log in, click a button (or whatever other method is available), and deploy their resources.
The entire goal of an IDP (and arguably, of Platform Engineering) is to make the lives of internal engineers and developers easier. No one can be an expert at everything, so it’s the job of a Platform Engineer to help ease this pain/expectation.
Let’s now talk about one of the most popular tools in the IDP space, Port.
What Is Port
When it comes to IDPs, they can come in all shapes and sizes. It could be anything from a CLI to an API to YAML to a GUI (which is what a lot of people see or think of when the idea of an IDP comes up). For example, you could create a CLI that abstracts away a chunk of an SDK and only exposes the portion of an SDK that the developers/engineers need. This will make their life easier as they don’t have to learn the entire SDK, all of the commands, and can just use what they need.
Port is what some categorize as an enterprise IDP in the sense that it has both free and paid options. It’s supported so engineers can get help if needed and it’s SaaS-based, so you don’t have to worry about hosting it on your own infrastructure.
The goal with Port is to give you an easy-to-use GUI for deploying and managing resources. These “resources” could be anything from a Kubernetes cluster to Pods to virtual machines.
What About Backstage?
Backstage is an open-source IDP that you may have heard of. It’s very popular, has a huge use case, and written/used in JavaScript, so people tend to like it. The key difference is you need to manage all of the plugins (every single one of them) and because of that, engineers may want to use something like Port as those plugins/integrations already exist for you.
Creating A Port Config In Self-Service
The first step is to ensure that you’re logged into Port. Once you’re logged in, you’ll see a screen similar to the one below (minus the resources that are there as this is my account, so you won’t see them).
Click on the Self-service option at the top of the page.
Within self-service, click the + Action button.
You can give your action a name, an icon to specify what environment it’s deploying to, and the Operation type. As an example in the screenshot below, you can choose Create.
Keep in mind that the Create button is just metadata and so is the icon. You can choose “Day 2” understand the Operation and an AWS icon, yet still create an AKS cluster in Azure.
For the User Form, you can leave it blank for the purposes of this example. The User Form allows you to put in specific payloads for particular actions you may want to take within your environment.
In the Backend section is where you begin to define what your button/workflow is going to be. Notice how in the Invocation Type, you see a lot of options for pipelines. That’s because as a Platform Engineer, those backends (like a pipeline) are already supposed to exist.
Port isn’t creating that backend for you, it’s calling the backend.
Underneath the workflow trigger, you can see where you can point to the backend. For example, the screenshot below shows that it’s pointing to a GitHub Action.
Once you finish up the Backend, you can then give permissions to teams and users from an RBAC perspective within the Permissions tab.
Now that the workflow is created, you can deploy it.
Deploying With Port
Once the backend is created, in the Self-Service Hub, you’ll see your workflow with a button. Notice how the button shows the operation (create) and the icon that you chose.
Clicking the button brings you to a prompt that asks if you want to execute the workflow or not.
After clicking the teal Execute button, you’ll see that the workflow has kicked off.
After the resource is created successfully, you’ll see the status turn to Success.
Port is a great way to give engineers and developers a button to click for resources/workflows that a Platform Engineer creates to make their lives a bit easier and to ensure that everyone doesn’t have to become an SME.
