Platform Engineering: Warum Self-Service-Plattformen DevOps ablösen

DevOps war ein Paradigmenwechsel. Doch nach einem Jahrzehnt der „You build it, you run it”-Philosophie zeigt sich: Viele Teams sind überfordert, nicht untermotiviert. Platform Engineering ist die Antwort auf die Frage, wie man Entwicklern Autonomie gibt, ohne sie mit Infrastruktur-Komplexität zu erschlagen.

Das Problem mit „Full-Stack DevOps”

In der Theorie klingt es großartig: Entwickler deployen eigenständig, überwachen ihre Services, reagieren auf Incidents. In der Praxis bedeutet es oft:

• Jedes Team baut seine eigene CI/CD-Pipeline
• Terraform-Module werden kopiert statt geteilt
• Monitoring ist ein Flickenteppich aus Prometheus, Datadog und CloudWatch
• Onboarding neuer Entwickler dauert Wochen statt Tage

Das Ergebnis: Kognitive Überlastung, hohe Varianz zwischen Teams, und wiederkehrende Fehler, die längst gelöst sein sollten.

Was Platform Engineering anders macht

Im Kern geht es um eine Internal Developer Platform (IDP): Eine kuratierte Schicht zwischen Entwicklern und Infrastruktur, die Standardwege bietet und Guardrails setzt.

Die goldene Regel

Entwickler sollten sich um ihre Probleme kümmern (Businesslogik, Features, APIs) — nicht um unsere Probleme (Networking, Zertifikate, Cluster-Config).

Typische IDP-Komponenten

Komponente	Tool-Beispiele	Mehrwert
Service Catalog	Backstage, Port	„Was läuft wo?” auf einen Blick
Self-Service Deployments	ArgoCD, Flux	Git Push → Production
Template Engine	Cookiecutter, Yeoman	Neue Services in Minuten starten
Observability Stack	Grafana Cloud, Honeycomb	Einheitliche Dashboards für alle
Secrets Management	Vault, External Secrets	Keine Secrets in Code oder Env-Vars

Ein realistischer Einstieg (ohne 6-Monats-Projekt)

Woche 1–2: Inventory und Pain Points

Fragt eure Entwickler: Was kostet euch am meisten Zeit, das nicht euer Code ist?

Typische Antworten:

• „Kubernetes Manifeste schreiben”
• „DNS-Einträge beantragen”
• „SSL-Zertifikate konfigurieren”
• „Einen neuen Service aufsetzen”

Woche 3–4: Die ersten „Golden Paths”

Ein Golden Path ist ein vorgegebener, optimierter Weg für häufige Aufgaben. Beispiel:

# golden-path/new-service-template.yaml
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: new-microservice
  title: Neuen Microservice erstellen
spec:
  parameters:
    - title: Service-Details
      properties:
        name:
          type: string
          description: Name des neuen Service
        team:
          type: string
          description: Zuständiges Team
        language:
          type: string
          enum: [go, python, typescript]
  steps:
    - id: create-repo
      action: publish:github
    - id: deploy-infra
      action: deploy:kubernetes
    - id: setup-monitoring
      action: create:grafana-dashboard

Monat 2–3: Self-Service wachsen lassen

Nach den ersten Golden Paths: Feedback sammeln, iterieren, neue Paths für weitere Use Cases erstellen. Nicht versuchen, alles auf einmal zu bauen.

Kennzahlen, die zählen

Messt den Erfolg nicht an der Anzahl der Plattform-Features, sondern an:

• Time to First Deploy (wie schnell ist ein neuer Service live?)
• Onboarding Time (wie schnell ist ein neuer Entwickler produktiv?)
• Cognitive Load Score (subjektive Bewertung der Teams)
• Change Failure Rate (sinkt sie mit standardisierten Deployments?)

Was ich im Markt beobachte

• Backstage (Spotify) hat sich als De-facto-Standard für Service Catalogs etabliert
• Humanitec und Kratix adressieren die Orchestrierung hinter der IDP
• Cloud-Provider bieten eigene Platform-as-a-Service-Lösungen an (Azure Deployment Environments, GCP Workstations)
• Score als offener Standard für Workload-Spezifikation gewinnt an Traktion

Mein Take

Platform Engineering ist kein neues Label für DevOps — es ist die Erkenntnis, dass nicht jeder Entwickler ein Infrastruktur-Experte sein muss (oder will). Die besten Plattformen fühlen sich an wie ein Produkt, nicht wie ein Ticket-System. Fangt klein an, messt den Impact, und baut aus, was funktioniert.