Engineering Playbook

IDPs & Portals

Internal Developer Platforms, Backstage, and the Service Catalog.

Internal Developer Platforms (IDP)

As an organization scales, "You build it, you run it" becomes "You build it, you drown in it."

Developers spend too much time fighting Terraform, finding documentation, or figuring out who owns service-x. An IDP solves this by providing a unified interface for the underlying platform.

The Service Catalog

The core of any IDP is the Catalog. It answers:

  1. Ownership: Who owns this service? (Team, Slack channel, PagerDuty).
  2. Metadata: What language is it? Java? Go?
  3. State: Is it in Prod? Where is the CI pipeline?

Backstage (Spotify)

The open-source standard for building IDPs. It is a centrally managed portal that aggregates plugins.

  • Software Templates: Click a button -> Get a "Hello World" repo with CI/CD + Infra set up.
  • TechDocs: Markdown documentation living with the code, rendered in the portal.
  • Scorecards: Does this service meet our standards? (Has Readme? Has Alerting?)

Port / Cortex / Compass

Building Backstage is hard (it's a TypeScript app you have to maintain). SaaS alternatives like GetPort, Cortex, or Atlassian Compass provide the IDP experience out of the box.


The Maturity Model

  1. Wiki Page: A static list of services on Confluence. (Rotts instantly).
  2. Spreadsheet: Slightly better, but manual updates fail.
  3. Automated Catalog: Reads catalog-info.yaml from Git repos. (Backstage model).
  4. Self-Service Platform: Developers can click "Provision DB" and get an RDS instance without opening a ticket.

Product Thinking

Your Platform is a Product. Your developers are your Customers.

If the IDP is harder to use than the AWS Console, they won't use it. Measure adoption. Iterate based on feedback.