Platform Engineering: Building Internal Developer Platforms

Platform Engineering is the discipline of building self-serve internal platforms that abstract infrastructure complexity from development teams. Unlike traditional DevOps (where developers manage infrastructure), Platform Engineering provides golden paths—opinionated, pre-configured solutions that reduce cognitive load. Gartner predicts 80% of large enterprises will have platform teams by 2026. This guide covers architecture patterns, technology choices, and organizational design.

The Platform Engineering Model

flowchart TB
    subgraph Developers ["Product Teams"]
        Dev1["Team A"]
        Dev2["Team B"]
        Dev3["Team C"]
    end
    
    subgraph Platform ["Internal Developer Platform"]
        Portal["Developer Portal"]
        Templates["Service Templates"]
        CI["CI/CD Pipelines"]
        Infra["Infrastructure APIs"]
    end
    
    subgraph Infra ["Infrastructure"]
        K8s["Kubernetes"]
        Cloud["Cloud Resources"]
        Monitoring["Observability"]
    end
    
    Developers --> Portal
    Portal --> Templates
    Portal --> CI
    Portal --> Infra
    Templates --> K8s
    CI --> Cloud
    Infra --> Monitoring
    
    style Portal fill:#E1F5FE,stroke:#0277BD

Core Components

1. Developer Portal (Backstage)

Spotify’s Backstage is the de facto standard for internal developer portals:

• Service Catalog: Discover all services, owners, documentation
• Software Templates: Scaffold new projects with best practices
• TechDocs: Documentation from repos, rendered centrally
• Plugins: Integrate CI/CD, cloud resources, on-call

2. Golden Paths (Templates)

# Backstage Template - New .NET Service
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: dotnet-api
  title: .NET 6 API Service
spec:
  parameters:
    - title: Service Details
      properties:
        name:
          type: string
          title: Service Name
        owner:
          type: string
          title: Team
          ui:field: OwnerPicker
        database:
          type: boolean
          title: Include PostgreSQL?
  steps:
    - id: fetch
      name: Scaffold
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
    - id: publish
      name: Create Repository
      action: publish:github
    - id: register
      name: Register in Catalog
      action: catalog:register

3. Infrastructure APIs (Crossplane)

Crossplane enables Kubernetes-style APIs for cloud resources:

# Developer requests a database via YAML
apiVersion: database.myplatform.io/v1
kind: PostgreSQLInstance
metadata:
  name: orders-db
spec:
  size: small
  version: "14"
  backup:
    enabled: true
    retention: 7d

The platform team defines PostgreSQLInstance as a composition of RDS instance, security groups, secrets, and IAM roles. Developers see a simple API.

Measuring Platform Success

Team Structure

• Platform Product Manager: Roadmap, developer research
• Platform Engineers: Build and maintain platform capabilities
• Developer Advocates: Onboarding, training, feedback loops

Treat the platform as a product. Product teams are your customers. Build what they need, not what’s technically interesting.

Anti-Patterns

• Mandating adoption: Platforms must be compelling, not forced
• Building without feedback: Talk to developers weekly
• Boiling the ocean: Start with one golden path, iterate
• Ignoring escape hatches: Power users need raw access

Key Takeaways

• Platform Engineering provides self-serve internal platforms
• Backstage is the standard for developer portals
• Golden paths reduce cognitive load with opinionated defaults
• Infrastructure APIs (Crossplane) abstract cloud complexity
• Measure platform success with developer experience metrics
• Treat the platform as a product with dedicated PM