Building Internal Developer Platforms

The Developer Platform Imperative

A new engineer joins. They need:

• Local development environment
• Database access
• Deployment permissions
• Monitoring dashboard
• Documentation

Without a platform: 1-2 weeks of setup, manual handoff, tribal knowledge.

With a platform: click a button, 10 minutes, fully onboarded.

An internal developer platform (IDP) is infrastructure for developers. Self-service, standardized, automating toil.

What an IDP Provides

1. Onboarding: New service from template, 5 minutes
2. Environments: Dev, staging, production with one command
3. Deployment: Git push = deploy (GitOps)
4. Monitoring: Pre-configured dashboards, alerts, logs
5. Access control: Self-serve secrets, API keys, database credentials
6. Documentation: Auto-generated from code
7. Cost visibility: Who's spending what?

Self-Service Onboarding

Without platform:

Engineer: "How do I start a new service?"
Platform engineer: "See the wiki. Run these 50 commands. Copy this config. Now you're set."
Engineer: "Why is X different from Y in the existing services?"
Platform engineer: "Long story..."
Engineer (1 month later): "Guys, I broke CI/CD for everyone. Didn't know about that constraint."

With platform:

Engineer: Click "Create new service"
  ↓ Fill form (service name, language, features)
  ↓ Platform generates service from template
  ↓ Git repo created, CI/CD configured, deployment pipeline ready
  ↓ "Welcome! Your service is live at https://myservice.dev.mycompany.com"

Platform template (Cookiecutter, Yeoman):

# Service template
name: {{ service_name }}
language: {{ language }}
features:
  - database: {{ include_db }}
  - queue: {{ include_queue }}
  - cache: {{ include_cache }}

# Generated: Dockerfile, docker-compose.yml, Kubernetes manifests, CI/CD pipeline, README

All new services follow the same structure. No variance. No surprises.

Standardized Deployment Pipeline

Git push to main
  ↓
CI pipeline runs (build, test, lint, scan)
  ↓
If all pass, build Docker image
  ↓
Push to registry with git SHA tag
  ↓
Deploy to staging
  ↓
Run smoke tests
  ↓
Wait for approval (or auto-promote)
  ↓
Deploy to production (blue-green or canary)

All services use same pipeline. Consistency across 100 services.

Infrastructure-as-Code (Terraform, Helm):

# services/myservice/main.tf
module "myservice" {
  source = "../../modules/service"

  name = "myservice"
  image = var.image_tag  # Provided by CI/CD
  replicas = 3

  environment = {
    DATABASE_URL = "postgres://prod.db:5432/myservice"
    REDIS_URL = "redis://prod.cache:6379"
  }
}

Engineer updates Terraform. Runs terraform plan locally. CI validates, applies.

Developer Experience

Command to deploy:

deploy --service myservice --version 1.2.3
# Automatic: find image tag, update Kubernetes, monitor rollout, verify health

Self-serve database provisioning:

platform db create --service myservice --type postgres --size 50gb
# Automatic: provision RDS, configure backups, add connection string to secrets

Monitoring dashboard (pre-configured):

platform dashboard --service myservice
# Automatic: create Grafana dashboard with latency, error rate, CPU, memory

Cost Attribution

Track who's spending what.

Team: payments-api
Services: 10
Monthly cost: $12,000
  - Compute: $8,000 (35 pods)
  - Database: $3,000 (900GB)
  - Cache: $1,000 (10GB Redis)

Alert when cost spikes. Engineers see immediate feedback: "That new feature costs $2k/month extra. Worth it?"

Implemented in Kubernetes with cost labels:

apiVersion: v1
kind: Pod
metadata:
  labels:
    cost-center: engineering
    team: payments
    service: payments-api

Tools: Kubecost, CloudZero.

Platform Engineering Team

Who builds the platform?

Small team (5-10 people) for 100+ engineers.

Responsibilities:

• Maintain templates and best practices
• Manage CI/CD infrastructure
• On-call for platform issues (if deployment breaks, platform team pages)
• Collect feedback from engineers
• Iterate platform based on needs

Not responsible for:

• Application debugging (engineer's job)
• Business logic testing (engineer's job)
• Production on-call (application team's job, supported by platform)

Platform team goal: remove toil, not add process.

Evolution: From Manual to Platform

Phase 1 (6 months): Manual processes

• Engineers SSH into servers
• Manual deployments
• No standardization
• Chaos

Phase 2 (6-12 months): Scripted

• Shell scripts automate common tasks
• Still manual, but faster
• Some standardization

Phase 3 (12-18 months): Platform v1

• Self-service infrastructure
• Basic templates
• Automated CI/CD
• Cost visibility

Phase 4 (18+ months): Platform v2

• Advanced features (policy enforcement, advanced monitoring)
• Better DX (IDE integrations, local preview)
• AI/ML-powered recommendations
• Cross-team collaboration features

Move to Phase 3 before scaling to 100+ engineers.

Platform Engineering Checklist

• Service templates (standardized structure)
• Automated CI/CD pipeline (all services use same pipeline)
• Self-service deployment (no manual steps)
• Pre-configured monitoring (dashboards, alerts, logs)
• Secrets management (self-serve access)
• Cost attribution (see what you're spending)
• Runbooks (common troubleshooting)
• Documentation (auto-generated)
• Platform team (small, focused on DX)
• Feedback loop (engineers shape platform evolution)