What makes a self-service platform efficient?
Or more importantly, what makes a self-service platform useful for the Platform Engineers implementing it and the engineers/developers using it?
In this blog post, you’ll learn about one solution you can use as an IDP as well as a general deployment method and why IDP’s are necessary.
Why an IDP Is Important
Internal Developer Platforms (IDP) have been used for years, they’ve just typically been called self-service portals. Although IDP’s expand what a typical self-service portal is, that’s more or less the concept.
An IDP gives Platform Engineers the ability to create self-service capabilities for internal engineering departments and developers. The entire goal is to reduce cognitive load. For example, let’s say you’re a developer that needs to deploy a containerized application. The problem is, you don’t know enough about Kubernetes, Kubernetes Manifests, and other various methods to deploy containerized applications. You know you need to, but it’s not in your area of expertise. A Platform Engineer can create a button for you to click to deploy the containerized application. Underneath the hood, the inner workings of Kubernetes and Manifests are there, but you don’t know about them. All you know is there’s a button you can click to deploy an application.
Cognitive relief obtained; confusion eliminated.
The IDP Ecosystem
As of right now when it comes to IDP’s, there are two primary methods:
- Homegrown
- Enterprise
Homegrown can be thought of as an open-source method. It essentially means that on paper, it’s free, but that doesn’t mean it lifts all financial burden. Homegrown solutions must be implemented on systems, managed, deployed, and monitored. That means there will not be something like a Software-as-a-Service (SaaS) option. Where you save money in paying for the tool, you spend it in hiring engineers to manage the homegrown solution and system that it resides on.
Enterprise means you’re paying for a solution. Although it’s paid, what it allows you to do is not worry about the underlying system to run it. This saves a ton of money if you’re, for example, running the system that’s running the homegrown solution in the cloud. It also saves you from having to do things like set up monitoring, observability, and automation around deploying and managing the system. If it’s SaaS, that means it’s all done for you.
💡 Devtron has a paid solution for enterprises and a completely free version for small teams. Devtron is also making parts of its platform open-source, so you have the ability to get the best of both worlds.
At the end of the day, there are pros and cons to each method. There’s no right or wrong answer. It comes down to how an organization wants to spend its money.
Implementing Devtron As An IDP
An IDP needs two primary components:
- A method for Platform Engineers to automate and manage how Platform Capabilities will reach systems. For example, a method for getting ArgoCD deployed to a cluster.
- A button-click or automated approach for developers and engineers using the platform to get the Platform Capabilities deployed.
In this section, let’s talk about a few methods that Devtron uses to accomplish both tasks.
💡 Devtron isn’t just an IDP. It can absolutely be used as one, but that’s not it’s only implementation method.
The two primary components mentioned above can be a full list of various tools and methods within itself, so let’s touch on two of the primary things that you’ll see within a Platform Engineering Application Stack - Kubernetes and ArgoCD.
First, ArgoCD.
Out of the box, Devtron gives you the ability to use ArgoCD for Continuous Deployment/Delivery and a built-in CICD integration. The purpose of Devtron isn’t to create new tools for you to use, but instead to implement the existing tools you already use in one place, so it makes sense to have the popular Platform Engineering tools built in.
Read more about ArgoCD: Standalone Configuration vs Devtron Configuration blog and learn more about the true potential of ArgoCD with Devtron!
Devtron uses the method of looking at where your source code exists and building/deploying software from the repository. All of the logic still lives in the source control system. Devtron just pulls from it to build and deploy the artifact to Kubernetes. It then continuously deploys said artifact (like a Kubernetes Manifest) based on change via ArgoCD.
The second way Devtron can help from an IDP perspective is by giving internal engineers and developers an easier way to interact with Kubernetes. A Platform Engineers job is still to maintain Devtron itself (because it’s installed on a Kubernetes cluster), the underlying Kubernetes cluster, and the tools, but the internal engineers/developers using the Kubernetes platform that the Platform Engineers built can be used from Devtron.
This is done via the Devtron Resource Browser.
The Resource Browser gives the ability to manage Kubernetes resources from one GUI without having to fumble around with Kubectl and YAML. You can manage all Kubernetes resources from Pods and Services to Custom Resources.
From a Platform Engineering perspective, this is great as one of the primary needs is to make Kubernetes easier to interact with for the internal engineers and developers deploying containerized workloads.
Wrapping Up
Internal Developer Platforms are the newest iteration of self-service. Although self-service has been around for a while, the idea of building it to give to internal engineers and developers is a bit new. It’s been done for a while, but the terms “Platform Engineering” and “IDP” are new. Because of that, there’s a lot of hype around it right now. To get through the hype, ensure that you understand exactly what you need out of an IDP and more importantly, what the internal engineering teams need to use it for.
If you have any queries, don't hesitate to connect with us. Join the lively discussions and shared knowledge in our vibrant Discord Community.
