↓Skip to main content

Internal Developer Platforms

Development

An internal developer platform(IDP) is tooling used by your team to build and manage infrastructure, services and applications within an organization effectively.

The terms “internal developer platform” and “internal developer portal” are used interchangably in most contexts. I think portal is an interface to consume the platform. So, what problems does it solve?

  1. IDPs provide a standard and consistent interface for developers. Want to create a new RDS for the performance test? There should be a standard issue RDS instance from the IDP’s catalog.

  2. Security. Developers won’t accidentally create resources above their paygrade. They just won’t have appropriate permissions to do so. Combine that with some kind of policy interface like OPA, you got yourself a robust and secure IDP.

  3. Efficiency. Developers can focus on providing business value. IDPs act as a bridge between the ops team and dev teams, thus providing shared visibility in the application lifecycle.

  4. Discoverability. Developers can login and find out a list of all the applications from the organization’s universal catalog, access the documentation.

What makes a good IDP?

  1. It has a decent UI. There is always a case of clickops and the world needs more clickops tooling.
  2. good API. Not a deal breaker, but having a REST API helps integrate with rest of the ecosystem.
  3. Extensible. It should be easy to extend the functionality of an IDP using plugins. Backstage’s architecture is an ideal example of this.
  4. Optionally, a good CLI.

Using IDPs to build a Kubernetes self-service platform #

Backstage based IDP for managing Kubernetes clusters and applications

This is a cool idea I want to flirt with as a side project. The objective is to build something like Heroku using OSS tooling and Backstage. This will

  1. … manage lifecycle of Kubernetes clusters in AWS, Azure and GCP. In the backend, it will happen using Crossplane. (There isn’t a Crossplane plugin for Backstage at the time of writing this.) The cloud credentials will be managed using Vault(There! we need a Backstage Vault plugin as well now.).
  2. … manage a set of tooling on top of Kubernetes clusters, like ingresses, storage, logging and monitoring via Crossplane.
  3. … manage access to the clusters for all the users using a centralized IAM(preferably Keycloak). Thus, it’ll be easy to integrate with other OIDC providers.
  4. … manage application lifecycle using Helm charts on these clusters, with the ability to provide standardized Helm charts(this could be managed as an entity).

In short, it will be a Rancher clone built by assembling a lot of CNCF ecosystem tools.

↑