Platform Engineering: Wie man eine Internal Developer Platform aufbaut

Da Softwaresysteme immer komplexer werden - Microservices, Kubernetes, Multi-Cloud, CI/CD-Pipelines, Observability-Stacks - verbringen Entwickler mehr Zeit mit Infrastruktur und weniger Zeit mit der Entwicklung von Produkten. Platform Engineering löst dieses Problem, indem eine interne Plattform geschaffen wird, die Komplexität abstrahiert und Entwicklern Self-Service-Tools bietet, um schneller zu liefern.

Gartner prognostiziert, dass bis 2027 80 % der Software-Engineering-Organisationen Plattformteams einrichten werden. In diesem Leitfaden werden wir untersuchen, was Platform Engineering ist, warum es wichtig ist und wie man eine Internal Developer Platform von Grund auf aufbaut.

Was ist Platform Engineering?

Platform Engineering ist die Disziplin des Entwerfens und Aufbauens von Toolchains und Workflows, die Self-Service-Fähigkeiten für Software-Engineering-Organisationen ermöglichen. Das Ergebnis ist eine Internal Developer Platform (IDP) - eine Schicht, die zwischen Entwicklern und Infrastruktur liegt.

Platform Engineering vs DevOps

Platform Engineering ist kein Ersatz für DevOps - es ist die nächste Evolution. DevOps sagte: „Du baust es, du betreibst es." Platform Engineering sagt: „Wir machen das Bauen und Betreiben mühelos."

Warum Platform Engineering wichtig ist

Das Problem der kognitiven Belastung

In einer typischen modernen Organisation muss ein Entwickler verstehen:

• Git-Workflows und Branching-Strategien
• CI/CD-Pipeline-Konfiguration
• Container-Erstellung und Registry-Verwaltung
• Kubernetes-Manifeste und Helm Charts
• Cloud-Provider-Dienste (AWS/GCP/Azure)
• Networking, DNS, TLS-Zertifikate
• Monitoring-, Logging- und Alerting-Einrichtung
• Datenbankbereitstellung und -migrationen
• Sicherheitsrichtlinien und Compliance

Das ist eine enorme kognitive Belastung, die den Fokus vom eigentlichen Produkt ablenkt.

Der Golden Path

Platform Engineering führt das Konzept der Golden Paths ein - meinungsstarke, gut unterstützte und dokumentierte Pfade für gängige Aufgaben. Ein Golden Path ist kein Zwang; Entwickler können abweichen, aber die Plattform macht das Richtige zum Einfachen.

Beispiel-Golden-Path für die Erstellung eines neuen Microservices:

1. Der Entwickler wählt „Neuer Backend-Service" im Portal
2. Wählt Sprache/Framework (Node.js, Go, Python)
3. Die Plattform erstellt automatisch: Git-Repository, CI/CD-Pipeline, Kubernetes-Namespace, Monitoring-Dashboards und Alerting-Regeln
4. Der Entwickler klont das Repository und beginnt sofort mit dem Programmieren

Aufbau einer Internal Developer Platform

Schicht 1: Developer Portal

Das Portal ist der zentrale Einstiegspunkt für Entwickler. Die beliebteste Open-Source-Option ist Backstage (von Spotify entwickelt, jetzt ein CNCF-Projekt).

Kernfunktionen:

• Service-Katalog: Jeder Service, sein Besitzer, Dokumentation und Abhängigkeiten
• Software-Templates: Scaffolding für neue Services mit integrierten Best Practices
• Technische Dokumentation: Dokumentation als Code, gerendert und durchsuchbar
• Plugin-Ökosystem: Erweiterbar mit individueller Funktionalität

# backstage/catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: user-service
  description: Manages user accounts and authentication
  annotations:
    github.com/project-slug: myorg/user-service
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-auth
  system: identity-platform
  dependsOn:
    - resource:postgresql-main
  providesApis:
    - user-api

Schicht 2: Infrastruktur-Abstraktion

Entwickler sollten Terraform oder Kubernetes-YAML nicht direkt schreiben. Die Plattform sollte Abstraktionen bereitstellen.

Werkzeuge:

• Crossplane: Kubernetes-native Infrastrukturbereitstellung
• Terraform mit Modulen: Vorgefertigte, getestete Infrastrukturmodule
• Pulumi: Infrastruktur als echter Code (TypeScript, Python, Go)

# Example: Crossplane composition for a database
apiVersion: database.example.com/v1
kind: PostgreSQLInstance
metadata:
  name: user-db
spec:
  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
  version: "16"
  backup: daily
  team: auth-team

Anstatt RDS-Parameter, VPC-Subnetze, Sicherheitsgruppen und Backup-Richtlinien zu konfigurieren, gibt der Entwickler einfach size: small und backup: daily an. Die Plattform erledigt den Rest.

Schicht 3: CI/CD-Standardisierung

Standardisiere CI/CD, damit Teams nicht jeweils eigene Pipelines bauen.

# .github/workflows/platform-ci.yml
# Teams just include the shared workflow
name: Build and Deploy
on:
  push:
    branches: [main]

jobs:
  pipeline:
    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
    with:
      language: node
      deploy-target: production
    secrets: inherit

Wichtige Praktiken:

• Gemeinsame CI/CD-Templates, die Teams einbinden (nicht kopieren)
• Automatische Sicherheitsscans (SAST, Dependency-Audit)
• Standardisierte Deployment-Strategien (Canary, Blue/Green)
• Automatisches Rollback bei fehlgeschlagenen Health Checks

Schicht 4: Observability

Vorkonfiguriertes Monitoring, damit Entwickler Dashboards und Alerts sofort einsatzbereit erhalten.

• Metriken: Prometheus + Grafana mit Standard-Dashboards pro Service
• Logging: Strukturiertes Logging mit zentraler Sammlung (Loki, ELK)
• Tracing: Verteiltes Tracing mit OpenTelemetry
• Alerting: PagerDuty/Opsgenie-Integration mit sinnvollen Standardeinstellungen

Erfolg messen

Woher wissen Sie, ob Ihre Plattform funktioniert? Verfolgen Sie diese Metriken:

DORA-Metriken

• Deployment-Frequenz: Wie oft Code die Produktion erreicht
• Lead Time für Änderungen: Zeit vom Commit bis zur Produktion
• Änderungs-Fehlerrate: Prozentsatz der Deployments, die Ausfälle verursachen
• Mittlere Wiederherstellungszeit: Zeit zur Wiederherstellung des Dienstes nach einem Vorfall

Plattformspezifische Metriken

• Zeit bis zum ersten Deploy: Wie lange vom „neuen Service" bis zum ersten Produktions-Deploy
• Entwicklerzufriedenheit (NPS): Befragen Sie Ihre Nutzer regelmäßig
• Self-Service-Quote: % der Infrastrukturanfragen, die ohne Tickets bearbeitet werden
• Golden-Path-Adoption: % der Services, die dem empfohlenen Pfad folgen

Häufige Fehler

1. Zu viel zu früh bauen

Beginnen Sie mit dem größten Schmerzpunkt, nicht mit einer großen Vision. Wenn Deployments schmerzhaft sind, fangen Sie dort an. Wenn Provisioning Wochen dauert, fangen Sie dort an.

2. Die Plattform nicht als Produkt behandeln

Das Plattformteam braucht einen Product Manager, Nutzerforschung und Feedback-Schleifen. Entwickler sind Ihre Kunden - verstehen Sie ihre Bedürfnisse.

3. Vorschreiben statt anziehen

Die besten Plattformen werden freiwillig adoptiert, weil sie das Leben der Entwickler einfacher machen. Wenn Sie die Nutzung vorschreiben müssen, ist Ihre Plattform nicht gut genug.

4. Developer Experience ignorieren

Eine Plattform mit schlechter UX wird nicht genutzt. Investieren Sie in klare Dokumentation, hilfreiche Fehlermeldungen und schnelle Feedback-Schleifen.

Erste Schritte

Eine praktische Roadmap zum Aufbau Ihrer ersten IDP:

Minimum Viable Platform

1. Service-Katalog (Backstage) - wissen, was existiert und wem es gehört
2. Ein Service-Template - Golden Path für Ihren häufigsten Service-Typ
3. Standardisierte CI/CD - gemeinsame Pipeline, die Teams einbinden
4. Grundlegende Dokumentation - wie man die Plattform nutzt, wo man Hilfe bekommt

Sie können dieses MVP in 2-3 Monaten mit einem Team von 2-3 Ingenieuren aufbauen.

Fazit

Platform Engineering bedeutet nicht, am ersten Tag die perfekte Plattform zu bauen. Es geht darum, die kognitive Belastung der Entwickler schrittweise zu reduzieren, damit sie sich auf die Produktentwicklung konzentrieren können. Fangen Sie klein an, messen Sie die Wirkung und iterieren Sie basierend auf dem Feedback der Entwickler.

Organisationen, die in Platform Engineering investieren, werden einen erheblichen Wettbewerbsvorteil haben: schnellere Lieferung, zufriedenere Entwickler und zuverlässigere Systeme.

Ressourcen:

• Team Topologies - das Buch, das Plattformteams populär gemacht hat
• Backstage - Spotifys Open-Source-Entwicklerportal
• CNCF Platforms White Paper - Community-Definition und Best Practices
• platformengineering.org - Community, Events und Ressourcen