Internal Developer Platforms (IDP) Explained

Platform engineering is having a moment. The idea: build an Internal Developer Platform (IDP) that makes developers self-sufficient. Here’s what that actually means.

The Problem

Developers want to:

• Deploy their code
• Provision infrastructure
• Debug issues

DevOps/SRE teams become bottlenecks:

• Manual requests
• Tickets
• Waiting

Result: Slow delivery, frustrated developers, overworked ops.

The Solution: IDP

An Internal Developer Platform provides self-service capabilities:

Developer
    │
    ├── "I need a database" → Self-service portal → Database provisioned
    │
    ├── "Deploy to staging" → CI/CD → Deployed
    │
    └── "What's wrong?"     → Observability → Insights

No tickets. No waiting.

Core Components

1. Developer Portal

The entry point for developers:

┌─────────────────────────────────────────┐
│           DEVELOPER PORTAL               │
├─────────────────────────────────────────┤
│ [Service Catalog]                        │
│   • Create new service                   │
│   • Request database                     │
│   • Provision environment                │
│                                          │
│ [My Services]                            │
│   • user-service    [healthy] [logs]     │
│   • payment-api     [warning] [metrics]  │
│                                          │
│ [Documentation]                          │
│   • Getting started                      │
│   • Runbooks                             │
│   • Best practices                       │
└─────────────────────────────────────────┘

Backstage by Spotify is the leading open-source option.

2. Service Templates

Golden paths for creating new services:

# backstage template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: python-service
  title: Python Microservice
spec:
  parameters:
    - title: Service Info
      required:
        - name
        - owner
      properties:
        name:
          type: string
        owner:
          type: string
          ui:field: OwnerPicker
  
  steps:
    - id: fetch
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
    
    - id: publish
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.name }}

Developers click “Create Service” → get a production-ready repo with:

• Pre-configured CI/CD
• Standard project structure
• Monitoring integration
• Kubernetes manifests

3. Infrastructure Abstraction

Hide Kubernetes complexity:

# Developer writes (simple)
apiVersion: platform.company.io/v1
kind: WebService
metadata:
  name: user-api
spec:
  image: user-api:latest
  replicas: 3
  database:
    type: postgresql
    size: small
  ingress:
    host: api.example.com

Platform translates to:

• Deployment
• Service
• HPA
• PDB
• NetworkPolicy
• Ingress
• Database operator CRs

4. Self-Service Environments

# Request a preview environment
apiVersion: environments.platform.io/v1
kind: Environment
metadata:
  name: pr-123-preview
spec:
  ttl: 7d
  services:
    - name: frontend
      image: frontend:pr-123
    - name: backend
      image: backend:pr-123
  databases:
    - type: postgresql
      seedFrom: staging

Spin up environments on demand. Tear down automatically.

Technology Stack

Backstage (Developer Portal)

npx @backstage/create-app
cd my-backstage
yarn dev

Plugins for:

• GitHub/GitLab integration
• Kubernetes
• Cloud providers
• CI/CD systems
• Observability tools

Crossplane (Infrastructure)

# Define infrastructure as Kubernetes resources
apiVersion: database.aws.crossplane.io/v1beta1
kind: RDSInstance
metadata:
  name: my-db
spec:
  forProvider:
    dbInstanceClass: db.t3.micro
    engine: postgres
    masterUsername: admin

Kubernetes-native infrastructure provisioning.

Argo CD (GitOps)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://github.com/org/my-app
    path: k8s/
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Declarative, Git-driven deployments.

Implementation Strategy

Phase 1: Visibility

Start with documentation and service ownership:

• Catalog all services
• Document ownership
• Aggregate documentation

Low cost, high value.

Phase 2: Templates

Create golden paths for new services:

• Standard project templates
• Pre-configured CI/CD
• Security defaults

Reduce onboarding time.

Phase 3: Self-Service Infrastructure

Enable developers to provision resources:

• Database provisioning
• Environment creation
• Secret management

Reduce ops tickets.

Phase 4: Observability Integration

Unified view of system health:

• Metrics dashboards
• Log aggregation
• Distributed tracing

Developers debug their own issues.

Organizational Change

Platform Team

Treat the platform as a product:

Platform Team
├── Platform PM (yes, a PM)
├── Platform Engineers
├── Developer Advocates
└── Documentation Writers

Product Mindset

• User research (talk to developers)
• Feature prioritization
• Feedback loops
• Onboarding experience

Success Metrics

Pitfalls

Avoid: Building Everything Custom

❌ Building from scratch ✅ Use existing tools (Backstage, Crossplane, Argo CD)

Avoid: Forcing Adoption

❌ Mandate platform use ✅ Make the platform so good developers choose it

Avoid: Platform as Product Theater

❌ Platform team that doesn’t talk to developers ✅ Regular user research, feedback incorporation

Final Thoughts

Platform engineering is about developer experience. The goal is:

Developers focus on business logic, not infrastructure.

Build the platform with empathy. Treat developers as customers. Make the right thing the easy thing.

That’s what good infrastructure looks like.

Build roads, not roadblocks.