Internal Developer Platform

No Change
adopt
First Added:July 23, 2023 Updated: July 7, 2026

Internal Developer Platform is a technique we adopt in the garden.

Summary

This is not so much a platform itself, but rather the realization that a platform is needed for every team. This is a loose collection of items that are glued together to lessen developer cognitive burden.

Details

The IDP

The IDP isn’t a single thing. And there is no off-the-shelf solution to cover every case. Instead it is a mental framework for getting the right tooling glued together in a way that facilitates developers.

The Ops team specify the resources and templates used, when the developers trigger certain actions. The Ops team has to treat the IDP like any product team would and build it based on user research, maintain it, and continually improve it.

3 Panes of Glass

Everyone using the IDP needs 3 panes of glass:

  1. The IDE to code
  2. git to merge/push
  3. the IDP to ship

5 Core Components

The IDP needs to have at least 1 solution in each of the 5 areas. While multiple tools are possible in each area a goal should be the minimal set of useful tools.

Application Configuration Management

Manage config in a dynamic, scalable, and reliable way

  1. Store app config in git repos
  2. Reference template by Version (stored elsewhere as an artifact)
  3. Reference Secrets by name (not stored in git)
  4. Scope should encompass all aspects of the app (external and internal)
  5. External: DNS, DBs, Platform
  6. Internal: Helm chart

Infrastructure Orchestration

Orchestrate based on context

  1. This is the pipeline tool. It has to support configuration of all the following:
  2. Pipeline - build and deployment pipelines
  3. Compute / Clusters - Setting up and making ready any compute resources
  4. 2nd touch App setup - Setting up any additional things on top of the compute
  5. Artifact Registry - Push and Pull artifacts
  6. DNS - DNS should be real
  7. Certs - Certs should be real and tied to DNS
  8. Other Resources - Anything else that might be critical

Environment Management

Enable devs to create full envs

  1. Envs should be setup the following ways:
  2. Automatic for review - It is often useful, if feasible, for an testing ENV to automatically be setup based on standard actions like a PR. This will allow the developer to have a dedicated system during development, and allow the reviewer to use that env during reviews.
  3. Self service - Next best thing where the Devs can setup their own envs as they need them.
  4. By type / Shared - Ops needs to manage a static set of envs that are maintained over time.

Deployment Management

CD

  1. Ideal development process
  2. Git push - Developer pushing code is the start CI which usually ends in Artifacts being created
  3. Automated deploy - Newly built artifacts trigger automatic deployment
  4. Trigger next steps - After the deployment is successful it should be possible to trigger the next step. That might be:
  5. Run acceptance tests
  6. Deploy to another environment
  7. Notify 3rd parties (i.e., close a maintenance window)

Role-based Access Control

RBAC

Manage users and permissions

  1. RBAC ties into Enterprise SSO. The following would be org level roles
  2. Member - any member of the team, usually they can access the stuff they setup
  3. Service Account - machine level access
  4. manager - manage other users
  5. Admin - DevOps role
  6. Additionally the app or env usually has roles like
  7. Viewer - read-only access
  8. Contributor - can update config (usually also a “Member”)
  9. Owner - full admin (usually the one that deployed the env)

Tooling

https://internaldeveloperplatform.org/platform-tooling/