Port’s 2024 State of Internal Developer Platform reports 85% adoption of Internal Developer Portals and 99% adoption of platform engineering, with 83% incorporating GitOps into their approach. This report also affirms the following:
The market is still unclear about what constitutes an Internal Developer Platform.
With that in mind, I'll attempt to clarify the differences between an Internal Developer Portal (IDP) and an Internal Developer Platform (IDP). Unfortunately, they both have the same acronym, adding to the confusion. Below, I'll focus on Kubernetes app operations and refer to these IDPs as either IDPortal or IDPlatform.
The Cognitive Overload for Kubernetes Operations
Enterprise platform engineering and DevOps teams have to traverse multiple application development environments – virtualization, legacy, and modern applications (i.e., Kubernetes). Kubernetes is the de facto technology stack for containerized applications worldwide. However, Kubernetes is a complex system, particularly for multi-cloud, multi-cluster environments, requiring integration with multiple tools for observability, continuous delivery, security, etc. See graphic below:
Managing and operating containerized Kubernetes applications at scale, across various and diverse clusters, remains burdensome and requires significant cognitive load. Today's platform engineering teams have been tasked with reducing the cognitive load and friction within development and operations, as well as, lack of standardized tools and documented best-practices.
Backstage = IDPortal
To help increase developer productivity, platform engineers are adopting CNCF’s Backstage, an open-source project created as a services catalog for developers. Backstage's mission is to build an UI that presents a consolidated view of catalog of software services, software templates, search, Kubernetes distribution, documentation, etc. to facilitate the life of developers.
Backstage is simple to use. The software developer logs into the Backstage portal and chooses available services, like “deploy an application” or “set up a Kubernetes cluster.” On account of Kubernetes, Backstage has several plugins to cloud native and proprietary tools. But Backstage will do nothing without an IDPlatform.
The developer may be told to work on an AI application. But what is not mentioned is that the AI application still needs to be deployed in Kubernetes.
This is an important point to make, because there are many people, including members of the C-suite, thinking that building or using an IDPortal like Backstage is all that matters, because "that’s what the app developer interfaces to." And that’s correct. However, an IDPortal, even Backstage, will do nothing without an IDPlatform.
So, what's an IDPlatform?
For modern applications:
An IDPlatform comprises a stack of cloud native, GitOps-based open-source software tools that are needed to deploy, manage, and observe all Kubernetes clusters, in any cloud environment.
Developers and operations teams need an IDPlatform to solve Kubernetes problems i.e., complexity of set up, management, and continuous upgrades. They also need to reduce the steep learning curve and the need for multi-disciplinary technical expertise in-house i.e., Kubernetes, GitOps, multi-cloud, etc. Below is an example of what a cloud native IDPlatform should look like, for Kubernetes operations (in green):
IDPortal (Backstage) + Cloud Native IDPlatform (KAOPS)
Platform engineering and DevOps teams can set themselves up for success by understanding that Backstage delivers a nice UI (IDPortal) for developers, but it still needs an IDPlatform for an application environment.
If you don’t have an IDPlatform like KAOPS that knows how to deploy things to Kubernetes, the IDPortal i.e., Backstage won’t do anything. All it will be is a nice UI that has no effective backend to it - and your developer can’t deploy anything.
An IDPlatform like KAOPS provides ease of extensibility, ease of use, and fast onboarding. KAOPS is a purpose-built IDPlatform that hides the complexity of Kubernetes operations to accelerate time-to-success, with enhanced observability and management tools. It's up to platform engineering teams to "pick their battles" to avoid wasting time trying to do something that has already been done successfully by someone else.
Backstage, IDPs, KAOPS, Kubernetes Operations
When you hear the acronym IDP being mentioned, don't be shy. Ask for clarification: "Do you mean an IDPortal like Backstage or an IDPlatform like KAOPS?" After all, now you know that not all "IDPs" serve the same purpose.
Also, when addressing Kubernetes problems, don't reinvent the wheel. Consider using an IDPlatform SaaS like KAOPS as your "easy button" for Kubernetes application operations, accessible via a plug-in to Backstage, or as a standalone solution. It works either way.
Last, consider the importance of freeing up internal senior technical experts to work on newer projects.
In sum, solving Kubernetes operational challenges with IDP Backstage alone is not enough. You also need the power of a cloud native IDPlatform (as a plug-in) delivering ease of use and smart automation for junior staff to quickly ramp up app delivery, deployment, and upgrades across clusters and cloud, with consistency and governance.
Comments