🏗️ What is Platform Engineering?

Platform engineering is the discipline of building and operating Internal Developer Platforms (IDPs) — self-service infrastructure and tooling that lets application developers ship faster without requiring deep Kubernetes knowledge. The platform team is the "team that serves teams."

Kubernetes is the foundation, but the IDP abstracts it. Developers interact with higher-level constructs (environments, services, pipelines) while the platform team maintains the underlying complexity.

🛤️ Golden Paths & Backstage

Golden Path — Microservice Template

A golden path is a Cookiecutter/Helm/Backstage template that generates a fully configured, production-ready service skeleton in one command. It encodes your organisation's standards.

# What a golden path microservice template generates:
my-service/
├── Dockerfile                    # multi-stage build, non-root user
├── .github/workflows/
│   └── build-push.yaml          # CI: test → build → sign → push to Harbor
├── helm/
│   └── my-service/
│       ├── Chart.yaml
│       └── values.yaml          # pre-configured: resources, probes, HPA
├── k8s/
│   ├── namespace.yaml           # with PodSecurity labels + quota
│   ├── service-account.yaml     # IRSA annotation
│   └── argocd-app.yaml          # ArgoCD Application pointing to this repo
└── backstage/
    └── catalog-info.yaml        # service registration in Backstage

Backstage — Service Catalog

Backstage is a CNCF incubating project (from Spotify) that provides a unified developer portal: service catalog, software templates, TechDocs, and plugin ecosystem.

# catalog-info.yaml — register a service in Backstage
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Handles payment processing
  annotations:
    github.com/project-slug: my-org/payment-service
    backstage.io/techdocs-ref: dir:.
    grafana/dashboard-selector: "title=Payment Service"
    argocd/app-name: payment-service-prod
  tags: [payments, critical, java]
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: checkout-platform
  dependsOn:
    - component:fraud-service
    - resource:postgres-payments

Backstage Software Template

# Software template — "Create a new microservice" in Backstage UI
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: microservice-template
  title: New Microservice (Golden Path)
  description: Creates a production-ready microservice with CI/CD, monitoring, and ArgoCD
spec:
  owner: platform-team
  type: service
  parameters:
    - title: Service Details
      properties:
        serviceName:
          type: string
          description: Name of the service (lowercase, kebab-case)
        owner:
          type: string
          description: Owning team
          ui:field: OwnerPicker
        language:
          type: string
          enum: [go, java, python, node]
  steps:
    - id: fetch-template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          serviceName: ${{ parameters.serviceName }}
          owner: ${{ parameters.owner }}
    - id: publish
      action: publish:github
      input:
        repoUrl: github.com?repo=${{ parameters.serviceName }}&owner=my-org
    - id: register
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: /backstage/catalog-info.yaml

🔌 Platform Abstractions with Operators

Platform teams build custom CRDs and operators that provide high-level abstractions over raw Kubernetes primitives. Developers interact with Application and Environment objects — the operator expands them into Deployments, Services, Ingresses, HPA, PDB, and all the other scaffolding.

Custom Application CRD

# Developer writes this — 30 lines instead of 300
apiVersion: platform.example.com/v1
kind: Application
metadata:
  name: payment-service
  namespace: team-payments
spec:
  image: harbor.example.com/payments/payment-service:v2.1.0
  replicas:
    min: 2
    max: 20
    targetCPU: 70
  port: 8080
  resources:
    cpu: "500m"
    memory: "512Mi"
  ingress:
    host: payments.example.com
    tls: true
  env:
    - name: DB_HOST
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: host
  healthCheck:
    path: /health
    port: 8080

The Application Operator reconciles this into:

• Deployment with resource requests, liveness/readiness probes, securityContext
• Service + Ingress with TLS (cert-manager annotation auto-added)
• HorizontalPodAutoscaler (min/max/targetCPU)
• PodDisruptionBudget (minAvailable: 1 auto-set)
• ServiceMonitor for Prometheus scraping
• NetworkPolicy (default-deny + allow ingress-controller ingress)

Environment CRD — Ephemeral Preview Environments

# Create a full preview environment from a PR
apiVersion: platform.example.com/v1
kind: Environment
metadata:
  name: pr-1234
  namespace: previews
  annotations:
    platform.example.com/pr: "1234"
    platform.example.com/ttl: "48h"   # auto-delete after 48h
spec:
  source:
    repo: my-org/payment-service
    branch: feature/new-checkout
  services:
    - name: payment-service
      image: harbor.example.com/payments/payment-service:pr-1234
    - name: postgres
      type: ephemeral-database     # operator provisions a temp DB
  domain: pr-1234.preview.example.com

Platform Tools Ecosystem

👥 Platform Team Operating Model

Team Topologies — Platform as Product

The platform team is a Enabling Team or Platform Team in the Team Topologies model. They treat the IDP as an internal product — with a roadmap, SLAs, user research, and regular developer surveys. The key shift: the platform team serves developers, not the other way round.

DORA Metrics — How to Measure Platform Impact

IDP Maturity Model

📝 Knowledge Check