Part 14: Platform Engineering

The Rise of Platform Engineering

Platform engineering is the discipline of building and maintaining Internal Developer Platforms (IDPs) — self-service layers that abstract away infrastructure complexity and enable development teams to deliver software faster, safer, and with less cognitive load.

For the past decade, organizations adopted DevOps with the mantra "you build it, you run it." While this fostered ownership, it also shifted enormous cognitive burden onto developers. Teams now needed to understand Kubernetes manifests, Terraform modules, CI/CD pipelines, networking policies, secrets management, monitoring dashboards, and dozens of other operational concerns — on top of actually writing application code.

The Evolution: Ops → DevOps → SRE → Platform Engineering

Understanding how we arrived at platform engineering requires tracing the history of software operations:

• Traditional Ops (pre-2009) — Separate operations teams managed servers. Developers threw code "over the wall." Deployment cycles measured in months.
• DevOps (2009+) — Broke down silos between dev and ops. Shared responsibility, automation, CI/CD. Faster deployments but increased developer cognitive load.
• SRE (2016+) — Google's approach: engineering applied to operations. Error budgets, SLOs, toil reduction. Focused on reliability but still required deep operational knowledge.
• Platform Engineering (2020+) — Build golden paths that abstract complexity. Developers get self-service with guardrails. Platform as a product with internal users.

timeline
    title Operations Evolution
    section Traditional Ops
        Pre-2009 : Separate teams
                 : Manual deployments
                 : Ticket-driven changes
    section DevOps
        2009-2016 : Shared responsibility
                  : CI/CD automation
                  : Infrastructure as Code
    section SRE
        2016-2020 : Error budgets & SLOs
                  : Toil reduction
                  : Reliability engineering
    section Platform Engineering
        2020-Present : Internal Developer Platforms
                     : Golden paths & self-service
                     : Platform as a product
                            

The shift to platform engineering is driven by a fundamental realization: not every developer needs to — or wants to — become an infrastructure expert. By providing curated, self-service workflows (golden paths), platform teams multiply the productivity of the entire engineering organization.

Internal Developer Platforms (IDPs)

An Internal Developer Platform is a self-service layer that sits between development teams and the underlying infrastructure. It provides curated tools, workflows, and abstractions that let developers deploy, manage, and observe their applications without needing deep knowledge of every underlying technology.

The Five Core Components

Every mature IDP consists of five interconnected layers:

flowchart TB
    subgraph Developers["Developer Experience Layer"]
        DEV[Developer Teams]
        PORTAL[Developer Portal
Backstage / Port]
        GOLDEN[Golden Paths
Templates & Scaffolding]
    end
    subgraph Platform["Platform Layer"]
        ORCH[Infrastructure Orchestrator
Crossplane / Terraform]
        CONFIG[App Config Management
ArgoCD / Humanitec]
        OBS[Observability
Prometheus / Grafana]
    end
    subgraph Infra["Infrastructure Layer"]
        K8S[Kubernetes Clusters]
        CLOUD[Cloud Resources
AWS / Azure / GCP]
        DB[Databases & Caches]
        NET[Networking & DNS]
    end
    DEV --> PORTAL
    DEV --> GOLDEN
    PORTAL --> ORCH
    PORTAL --> CONFIG
    PORTAL --> OBS
    GOLDEN --> ORCH
    ORCH --> K8S
    ORCH --> CLOUD
    ORCH --> DB
    CONFIG --> K8S
    OBS --> K8S
    OBS --> CLOUD
    NET --> K8S
    NET --> CLOUD
                            

IDP Maturity Model

Organizations don't build an IDP overnight. Platform maturity progresses through levels:

Developer Experience (DevEx)

Developer experience is the sum of all interactions a developer has with the tools, processes, and systems they use to deliver software. Great DevEx means developers spend their time on business logic rather than fighting infrastructure.

Cognitive Load Theory Applied to Infrastructure

Cognitive load theory distinguishes three types of load:

• Intrinsic load — Complexity inherent to the task (writing business logic, designing APIs)
• Extraneous load — Unnecessary complexity from poor tooling (manual deployments, unclear docs)
• Germane load — Effort spent learning and integrating new knowledge

Platform engineering's primary goal is reducing extraneous cognitive load. When a developer needs to deploy a new microservice, they should not need to understand VPC configurations, IAM policies, Kubernetes RBAC, and certificate management. The platform abstracts these concerns into a simple, opinionated workflow.

flowchart LR
    subgraph Before["Without Platform"]
        B1[Write Code] --> B2[Configure CI/CD]
        B2 --> B3[Define K8s Manifests]
        B3 --> B4[Set Up Networking]
        B4 --> B5[Configure Secrets]
        B5 --> B6[Set Up Monitoring]
        B6 --> B7[Request DNS]
        B7 --> B8[Deploy]
    end
    subgraph After["With Platform"]
        A1[Write Code] --> A2[Push to Repo]
        A2 --> A3[Platform Handles Everything]
        A3 --> A4[Deployed & Observable]
    end
                            

Measuring Developer Experience

You cannot improve what you cannot measure. The industry uses several frameworks to quantify developer productivity and experience:

Backstage (Spotify's Developer Portal)

Backstage is an open-source platform for building developer portals, created by Spotify and donated to the CNCF. It provides a unified interface where developers can discover services, create new projects, access documentation, and integrate with any DevOps tooling.

Core Features

• Software Catalog — A centralized registry of all services, APIs, libraries, and infrastructure components with ownership and metadata
• Scaffolder (Software Templates) — Golden path templates that create new projects with all boilerplate pre-configured
• TechDocs — Documentation-as-code rendered alongside the services they describe
• Plugin Ecosystem — 100+ community plugins for Kubernetes, CI/CD, cost, security, and more

Software Catalog Configuration

Every component in Backstage is described by a catalog-info.yaml file that lives alongside the source code:

# catalog-info.yaml - Service registration in Backstage
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Handles payment processing and billing
  annotations:
    github.com/project-slug: myorg/payment-service
    backstage.io/techdocs-ref: dir:.
    prometheus.io/alert: "true"
  tags:
    - python
    - fastapi
    - payments
  links:
    - url: https://grafana.internal/d/payments
      title: Grafana Dashboard
      icon: dashboard
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: billing-platform
  providesApis:
    - payment-api
  consumesApis:
    - user-api
    - notification-api
  dependsOn:
    - resource:payments-db
    - resource:redis-cache

Register an API alongside the service:

# api-info.yaml - API definition for the catalog
apiVersion: backstage.io/v1alpha1
kind: API
metadata:
  name: payment-api
  description: REST API for payment processing
  tags:
    - rest
    - payments
spec:
  type: openapi
  lifecycle: production
  owner: team-payments
  system: billing-platform
  definition:
    $text: ./openapi.yaml

Scaffolder Templates

The Scaffolder lets you define golden path templates that create new projects with all best practices baked in:

# template.yaml - Backstage Scaffolder golden path template
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: microservice-python
  title: Python Microservice (FastAPI)
  description: Create a production-ready Python microservice with CI/CD, monitoring, and K8s deployment
  tags:
    - python
    - fastapi
    - recommended
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service Configuration
      required:
        - name
        - owner
        - system
      properties:
        name:
          title: Service Name
          type: string
          pattern: "^[a-z][a-z0-9-]*$"
          description: Lowercase with hyphens (e.g., payment-service)
        owner:
          title: Owner Team
          type: string
          ui:field: OwnerPicker
          ui:options:
            catalogFilter:
              kind: Group
        system:
          title: System
          type: string
          ui:field: EntityPicker
          ui:options:
            catalogFilter:
              kind: System
        description:
          title: Description
          type: string
    - title: Infrastructure Options
      properties:
        database:
          title: Database
          type: string
          enum: [none, postgresql, mysql, mongodb]
          default: postgresql
        cache:
          title: Cache
          type: string
          enum: [none, redis, memcached]
          default: redis
        environment:
          title: Initial Environment
          type: string
          enum: [development, staging, production]
          default: development
  steps:
    - id: fetch-template
      name: Fetch Skeleton
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
          system: ${{ parameters.system }}
          description: ${{ parameters.description }}
          database: ${{ parameters.database }}
          cache: ${{ parameters.cache }}
    - id: create-repo
      name: Create GitHub Repository
      action: publish:github
      input:
        allowedHosts: ["github.com"]
        repoUrl: github.com?owner=myorg&repo=${{ parameters.name }}
        defaultBranch: main
        protectDefaultBranch: true
    - id: register-catalog
      name: Register in Catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['create-repo'].output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml
    - id: create-argocd-app
      name: Create ArgoCD Application
      action: argocd:create-resources
      input:
        appName: ${{ parameters.name }}
        projectName: ${{ parameters.system }}
        repoUrl: ${{ steps['create-repo'].output.remoteUrl }}
        path: deploy/
  output:
    links:
      - title: Repository
        url: ${{ steps['create-repo'].output.remoteUrl }}
      - title: Open in Catalog
        icon: catalog
        entityRef: ${{ steps['register-catalog'].output.entityRef }}

Plugin Ecosystem

Backstage's power comes from its plugin architecture. Key plugins include:

Golden Paths

Golden paths (also called "paved roads") are opinionated, well-supported workflows for accomplishing common tasks. They represent the recommended way to do something — not the only way, but the easiest and best-supported path that the platform team maintains.

Designing Golden Paths

The key principle: start with the 80% use case. Golden paths should cover the most common scenarios perfectly, while still allowing escape hatches for edge cases.

Example golden paths for a typical organization:

Here's a Cookiecutter template structure for a golden path microservice:

# Golden path project structure generated by template
my-service/
├── .github/
│   └── workflows/
│       ├── ci.yaml              # Lint, test, build
│       ├── cd.yaml              # Deploy to staging/production
│       └── security.yaml        # SAST, dependency scanning
├── deploy/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   ├── hpa.yaml
│   │   └── kustomization.yaml
│   └── overlays/
│       ├── development/
│       ├── staging/
│       └── production/
├── src/
│   ├── main.py
│   ├── config.py
│   ├── health.py
│   └── routes/
├── tests/
│   ├── unit/
│   └── integration/
├── docs/
│   └── index.md               # TechDocs source
├── catalog-info.yaml          # Backstage registration
├── Dockerfile
├── Makefile
├── pyproject.toml
└── README.md

The CI workflow generated by the golden path:

# .github/workflows/ci.yaml - Generated by golden path template
name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install dependencies
        run: pip install -e ".[dev]"
      - name: Lint
        run: |
          ruff check .
          ruff format --check .
      - name: Type check
        run: mypy src/
      - name: Unit tests
        run: pytest tests/unit/ --cov=src --cov-report=xml
      - name: Upload coverage
        uses: codecov/codecov-action@v4

  build-and-push:
    needs: lint-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - name: Build and push image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: |
            ghcr.io/${{ "{{" }} github.repository {{ "}}" }}:${{ "{{" }} github.sha {{ "}}" }}
            ghcr.io/${{ "{{" }} github.repository {{ "}}" }}:latest

Infrastructure Abstraction

The fundamental question platform engineering answers is: "What level of infrastructure detail should developers see?" The answer is almost always "less than they see today." Infrastructure abstraction provides higher-level interfaces that hide the complexity of underlying cloud resources.

Why Developers Shouldn't Need to Know About VPCs

Consider what a developer needs to deploy a simple web application in a typical Kubernetes environment without abstraction:

• Deployment, Service, Ingress, HPA manifests
• Network policies, service mesh configuration
• PersistentVolumeClaims, StorageClasses
• ServiceAccounts, RBAC roles
• ConfigMaps, Secrets, ExternalSecrets
• Pod disruption budgets, resource limits

With proper abstraction, they should only need to express intent: "I want a web service with a database that handles 1000 requests per second."

Crossplane: Kubernetes-Native Infrastructure Abstraction

Crossplane extends Kubernetes with Custom Resource Definitions (CRDs) for infrastructure. It lets platform teams define high-level abstractions (Compositions) that developers consume through simple Claims:

flowchart TB
    subgraph Developer["Developer Interface"]
        CLAIM["Claim (XRC)
Simple intent: 'I need a database'"]
    end
    subgraph Platform["Platform Team Definitions"]
        XRD["CompositeResourceDefinition (XRD)
Defines the API/schema"]
        COMP["Composition
Maps claim to actual resources"]
    end
    subgraph Infra["Cloud Resources (Managed)"]
        RDS["AWS RDS Instance"]
        SG["Security Group"]
        SUBNET["DB Subnet Group"]
        SECRET["K8s Secret
(connection details)"]
        MONITOR["CloudWatch Alarms"]
    end
    CLAIM --> XRD
    XRD --> COMP
    COMP --> RDS
    COMP --> SG
    COMP --> SUBNET
    COMP --> SECRET
    COMP --> MONITOR
                            

Define the platform API with a CompositeResourceDefinition:

# crossplane/xrd-database.yaml - Platform team defines the abstraction
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xdatabases.platform.company.io
spec:
  group: platform.company.io
  names:
    kind: XDatabase
    plural: xdatabases
  claimNames:
    kind: Database
    plural: databases
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                engine:
                  type: string
                  enum: [postgresql, mysql]
                  description: Database engine type
                size:
                  type: string
                  enum: [small, medium, large]
                  description: T-shirt size for the database
                environment:
                  type: string
                  enum: [development, staging, production]
              required:
                - engine
                - size
                - environment

The Composition maps the simple claim to actual cloud resources:

# crossplane/composition-database.yaml - Maps claim to cloud resources
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: database-aws
  labels:
    provider: aws
    engine: postgresql
spec:
  compositeTypeRef:
    apiVersion: platform.company.io/v1alpha1
    kind: XDatabase
  resources:
    - name: rds-instance
      base:
        apiVersion: rds.aws.crossplane.io/v1alpha1
        kind: Instance
        spec:
          forProvider:
            engine: postgres
            engineVersion: "15"
            skipFinalSnapshot: true
            publiclyAccessible: false
            autoMinorVersionUpgrade: true
            backupRetentionPeriod: 7
      patches:
        - type: FromCompositeFieldPath
          fromFieldPath: spec.size
          toFieldPath: spec.forProvider.instanceClass
          transforms:
            - type: map
              map:
                small: db.t3.micro
                medium: db.r6g.large
                large: db.r6g.xlarge
        - type: FromCompositeFieldPath
          fromFieldPath: spec.size
          toFieldPath: spec.forProvider.allocatedStorage
          transforms:
            - type: map
              map:
                small: 20
                medium: 100
                large: 500
    - name: security-group
      base:
        apiVersion: ec2.aws.crossplane.io/v1alpha1
        kind: SecurityGroup
        spec:
          forProvider:
            description: Database security group
            ingress:
              - fromPort: 5432
                toPort: 5432
                protocol: tcp
                cidrBlocks:
                  - 10.0.0.0/16

Now developers consume this with a simple claim:

# developer-claim.yaml - What developers actually write
apiVersion: platform.company.io/v1alpha1
kind: Database
metadata:
  name: orders-db
  namespace: team-orders
spec:
  engine: postgresql
  size: medium
  environment: production

Self-Service Infrastructure

Self-service infrastructure means developers can provision, configure, and manage the resources they need without filing tickets or waiting for another team. The platform provides guardrails (cost limits, security policies, approved configurations) while giving developers freedom within those boundaries.

Ephemeral Environments

One of the highest-value self-service capabilities is on-demand preview/ephemeral environments that spin up for each pull request and automatically tear down when merged:

# .github/workflows/preview-env.yaml - Ephemeral environment per PR
name: Preview Environment
on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

jobs:
  deploy-preview:
    if: github.event.action != 'closed'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: |
          docker build -t ghcr.io/myorg/myapp:pr-${{ "{{" }} github.event.number {{ "}}" }} .
          docker push ghcr.io/myorg/myapp:pr-${{ "{{" }} github.event.number {{ "}}" }}
      
      - name: Deploy preview environment
        uses: company/deploy-preview@v2
        with:
          app-name: myapp
          pr-number: ${{ "{{" }} github.event.number {{ "}}" }}
          image: ghcr.io/myorg/myapp:pr-${{ "{{" }} github.event.number {{ "}}" }}
          database: postgresql-ephemeral
          ttl: 72h
      
      - name: Comment PR with preview URL
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: '🚀 Preview deployed: https://pr-${{ "{{" }} github.event.number {{ "}}" }}.preview.company.io'
            })

  cleanup-preview:
    if: github.event.action == 'closed'
    runs-on: ubuntu-latest
    steps:
      - name: Destroy preview environment
        uses: company/destroy-preview@v2
        with:
          app-name: myapp
          pr-number: ${{ "{{" }} github.event.number {{ "}}" }}

Self-Service Pipeline with Backstage

A complete self-service workflow using Backstage's scaffolder action:

# backstage/templates/new-environment/template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: provision-environment
  title: Provision New Environment
  description: Self-service environment provisioning with cost controls
spec:
  owner: platform-team
  type: environment
  parameters:
    - title: Environment Details
      required: [name, type, ttl]
      properties:
        name:
          title: Environment Name
          type: string
          pattern: "^[a-z][a-z0-9-]{2,20}$"
        type:
          title: Environment Type
          type: string
          enum: [development, testing, staging, demo]
          enumNames: [Development, Testing, Staging, Demo]
        ttl:
          title: Time to Live
          type: string
          enum: [24h, 72h, 1w, 2w, permanent]
          description: Environment auto-deletes after TTL
        budget:
          title: Monthly Budget Cap (USD)
          type: number
          default: 500
          maximum: 5000
  steps:
    - id: validate-budget
      name: Validate Budget
      action: http:backstage:request
      input:
        method: POST
        path: /api/cost-guardian/validate
        body:
          team: ${{ parameters.owner }}
          requestedBudget: ${{ parameters.budget }}
    - id: provision
      name: Provision Infrastructure
      action: crossplane:create
      input:
        manifest:
          apiVersion: platform.company.io/v1alpha1
          kind: Environment
          metadata:
            name: ${{ parameters.name }}
            annotations:
              platform.company.io/ttl: ${{ parameters.ttl }}
              platform.company.io/budget: "${{ parameters.budget }}"
          spec:
            type: ${{ parameters.type }}
            components:
              - kubernetes-namespace
              - database-postgresql-small
              - redis-cache
              - ingress

Platform Team Organization

How you organize the platform team determines whether the platform succeeds. The "Team Topologies" framework by Matthew Skelton and Manuel Pais provides the best model: the platform team operates as an enabling team that reduces cognitive load for stream-aligned (product) teams.

Platform vs DevOps vs SRE Teams

flowchart TB
    subgraph Stream["Stream-Aligned Teams (Product)"]
        T1[Team Alpha
Payments]
        T2[Team Beta
Search]
        T3[Team Gamma
Notifications]
    end
    subgraph Platform["Platform Team"]
        PT[Platform Engineers]
        IDP[Internal Developer Platform]
    end
    subgraph Enabling["Enabling Teams"]
        SRE[SRE Team]
        SEC[Security Team]
    end
    T1 -->|"Self-service via"| IDP
    T2 -->|"Self-service via"| IDP
    T3 -->|"Self-service via"| IDP
    PT -->|"Builds & maintains"| IDP
    SRE -->|"Consulting on reliability"| PT
    SEC -->|"Security policies"| PT
    SRE -.->|"Incident support"| T1
    SRE -.->|"Incident support"| T2
                            

Common Anti-Patterns

• Mandated Platform — Forcing teams onto the platform without earning their trust. If you mandate, you've already lost.
• No User Research — Building what platform engineers think developers need rather than what they actually need.
• Feature Factory — Adding capabilities without measuring adoption or removing unused features.
• Over-Abstraction — Hiding so much complexity that debugging becomes impossible when things go wrong.
• Under-Documentation — Building self-service workflows that nobody understands how to use.

A platform team charter template to prevent these anti-patterns:

# platform-team-charter.yaml
name: Platform Engineering Team
mission: >
  Reduce cognitive load for product teams by providing
  self-service, golden-path infrastructure that accelerates
  delivery while maintaining security and reliability standards.

principles:
  - Treat the platform as a product, developers as customers
  - Earn adoption through developer experience, never mandate
  - Measure everything: adoption, satisfaction, lead time
  - Golden paths are recommendations, not requirements
  - Abstract complexity but preserve debuggability

users:
  primary: Stream-aligned product teams (150 engineers)
  secondary: Data teams, ML teams (30 engineers)

success_metrics:
  - name: Time to first deployment (new developer)
    current: 2 weeks
    target: 1 day
  - name: Self-service adoption rate
    current: 30%
    target: 85%
  - name: Developer NPS
    current: 25
    target: 50
  - name: Lead time for changes
    current: 5 days
    target: 1 hour

roadmap_themes:
  q1: Golden path templates for top 3 languages
  q2: Self-service databases and caches
  q3: Ephemeral preview environments
  q4: Cost visibility and optimization

Measuring Platform Success

A platform without metrics is a platform without direction. You need both adoption metrics (are people using it?) and impact metrics (is it making them more productive?).

Implement a metrics dashboard for the platform itself:

{
  "dashboard": "Platform Engineering KPIs",
  "refresh": "1h",
  "panels": [
    {
      "title": "Self-Service Adoption Rate",
      "type": "gauge",
      "query": "sum(platform_requests_self_service) / sum(platform_requests_total) * 100",
      "thresholds": { "green": 80, "yellow": 60, "red": 0 }
    },
    {
      "title": "Time to First Deploy (P50)",
      "type": "stat",
      "query": "histogram_quantile(0.5, platform_first_deploy_duration_seconds_bucket)",
      "unit": "hours"
    },
    {
      "title": "Developer NPS Trend",
      "type": "timeseries",
      "query": "platform_developer_nps_score",
      "period": "quarterly"
    },
    {
      "title": "Golden Path Usage by Template",
      "type": "piechart",
      "query": "sum by (template) (platform_golden_path_invocations_total)"
    },
    {
      "title": "Platform Incident Count",
      "type": "stat",
      "query": "sum(increase(platform_incidents_total[30d]))",
      "thresholds": { "green": 0, "yellow": 3, "red": 5 }
    }
  ]
}

# Prometheus metrics exposed by the platform
# platform_metrics.py - Custom metrics for platform health
from prometheus_client import Counter, Histogram, Gauge

# Adoption metrics
golden_path_invocations = Counter(
    'platform_golden_path_invocations_total',
    'Number of times golden path templates are used',
    ['template', 'team']
)

self_service_requests = Counter(
    'platform_requests_self_service',
    'Self-service infrastructure requests',
    ['resource_type', 'team']
)

# Speed metrics
first_deploy_duration = Histogram(
    'platform_first_deploy_duration_seconds',
    'Time from new developer to first production deploy',
    buckets=[3600, 14400, 28800, 86400, 172800, 604800]
)

# Satisfaction
developer_nps = Gauge(
    'platform_developer_nps_score',
    'Developer Net Promoter Score for the platform'
)

Real-World Case Studies

Hands-On Exercises

# Exercise: Complete this golden path template
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: new-microservice
  title: # YOUR TITLE HERE
spec:
  owner: platform-team
  parameters:
    - title: Service Details
      properties:
        # Define your parameters
        name:
          type: string
        language:
          type: string
          enum: [python, go, java, node]
        # Add more parameters...
  steps:
    # Define your scaffolding steps
    - id: generate
      name: Generate project
      action: fetch:template
      input:
        url: ./skeleton
    # Add repo creation, catalog registration, etc.

# Exercise: Create catalog entries for an e-commerce system
---
apiVersion: backstage.io/v1alpha1
kind: System
metadata:
  name: # YOUR SYSTEM NAME
  description: # System description
spec:
  owner: # team name
---
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: # service-1
  annotations:
    # Add K8s, Grafana, PagerDuty annotations
spec:
  type: service
  lifecycle: production
  owner: # team
  system: # system reference
  providesApis: []
  consumesApis: []
  dependsOn: []

# Exercise: Test your ephemeral environment workflow
# 1. Create a branch and open a PR
git checkout -b feature/test-preview
echo "test" > test.txt
git add . && git commit -m "Test preview env"
git push origin feature/test-preview
# Open PR via GitHub CLI
gh pr create --title "Test Preview" --body "Testing ephemeral env"

# 2. Verify the preview environment is created
kubectl get namespaces | grep "pr-"
kubectl get pods -n pr-YOUR_PR_NUMBER

# 3. Access the preview URL and verify it works
curl -I https://pr-YOUR_PR_NUMBER.preview.company.io

# 4. Close the PR and verify cleanup
gh pr close YOUR_PR_NUMBER
# Wait 60 seconds for cleanup
kubectl get namespaces | grep "pr-"  # Should be gone

# Exercise: Define platform SLOs
# platform-slos.yaml
slos:
  - name: CI Pipeline Availability
    description: CI pipelines complete successfully
    sli:
      type: availability
      query: |
        sum(rate(ci_pipeline_runs_success_total[30d])) /
        sum(rate(ci_pipeline_runs_total[30d]))
    objective: 99.5%
    window: 30d
    error_budget_policy:
      - consumed: 50%
        action: Investigate trending issues
      - consumed: 75%
        action: Halt new feature work, focus on reliability
      - consumed: 100%
        action: Freeze deployments, all-hands incident response

  - name: # YOUR SLO 2 - Deployment Success Rate
    # Define your SLI, objective, and error budget policy

  - name: # YOUR SLO 3 - Developer Portal Latency
    # Define your SLI, objective, and error budget policy

Conclusion & Next Steps

Platform engineering represents the maturation of DevOps — the recognition that developer self-service must be designed, not just enabled. By building Internal Developer Platforms with golden paths, infrastructure abstraction, and developer portals, platform teams multiply the productivity of every engineer in the organization.

Key takeaways from this article:

• Platform as a product — Treat developers as customers, earn adoption through great experience
• Golden paths over golden cages — Recommend the best way without mandating the only way
• Abstraction with escape hatches — Hide complexity but preserve debuggability
• Measure relentlessly — Track adoption, satisfaction, and speed to prove platform value
• Start small, iterate fast — Begin with one golden path for the most common workflow and expand
• Crossplane for infrastructure APIs — Kubernetes-native abstraction that scales with your organization
• Backstage as the hub — Unified developer portal connecting all platform capabilities

Looking back across all 14 parts of this series, we have covered the complete infrastructure and cloud automation landscape:

• Parts 1-3: Foundations (Linux, networking, cloud fundamentals)
• Parts 4-6: Core tools (IaC with Terraform, configuration management, containers)
• Parts 7-9: Operations (security, Kubernetes, GitOps)
• Parts 10-12: Advanced practices (advanced Terraform, disaster recovery, CI/CD)
• Parts 13-14: Observability and platform engineering