Platform Engineering vs DevOps: Was sich wirklich geändert hat (und was nicht)

Der Wechsel von DevOps zu Platform Engineering

DevOps sagte "du baust es, du betreibst es." Jeder Entwickler verwaltet seine eigene Infrastruktur, deployt seine eigenen Services, konfiguriert sein eigenes Monitoring. In der Theorie schafft das Ownership. In der Praxis entstehen 15 verschiedene Wege, einen Service zu deployen, 8 verschiedene Monitoring-Setups, und jedes Team erfindet die gleiche CI/CD-Pipeline neu.

Platform Engineering ist die Korrektur. Statt dass jedes Team Infrastruktur von Grund auf baut, stellt ein Platform Team meinungsstarke, self-service-fähige Tools bereit, die das Richtige einfach und das Falsche schwer machen.

Der Wandel ist real, aber überverkauft. Für Teams unter 30 Ingenieuren ist Platform Engineering oft Overhead. Für Teams über 50 ist es notwendig. Dieser Artikel behandelt die praktischen Muster. Wie wir Infrastruktur deployen, findest du in unserem IaC-Guide und Kubernetes-Guide.

Was Platform Engineering wirklich ist

Platform Engineering ist kein Tool. Es ist nicht Backstage. Es ist nicht Kubernetes. Es ist ein Ansatz: baue interne Tools, die Entwickler produktiv machen, ohne dass sie Infrastruktur-Experten werden müssen.

Die Kernmetrik: Time to first deploy für einen neuen Service. Wenn ein Entwickler 2 Tage braucht, um von "Ich brauche einen neuen Service" zu "Er läuft im Staging" zu kommen, hat deine Plattform ein Problem. Wenn es 15 Minuten dauert, funktioniert deine Plattform.

Golden Paths

Ein Golden Path ist ein meinungsstarkes Template zum Erstellen eines neuen Services. Es enthält alles, was ein Entwickler braucht: Projektstruktur, CI/CD-Pipeline, Dockerfile, Kubernetes-Manifeste, Monitoring-Konfiguration und Dokumentation.

golden-path-typescript-api/
├── src/
│   ├── index.ts                    # Einstiegspunkt mit Health Check
│   ├── routes/                     # Route-Definitionen
│   └── services/                   # Business-Logik
├── test/
│   ├── unit/
│   └── integration/
├── Dockerfile                      # Optimierter Multi-Stage Build
├── .github/workflows/
│   └── ci-cd.yaml                  # Build, Test, Push, Deploy
├── kubernetes/
│   ├── base/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   └── overlay/
│       ├── staging/
│       └── production/
├── monitoring/
│   ├── alerts.yaml                 # Standard-Alert-Regeln
│   └── dashboard.json              # Grafana-Dashboard-Template
├── docs/
│   └── runbook.md                  # Runbook-Vorlage für den Betrieb
├── .env.example
├── package.json
├── tsconfig.json
└── README.md

Ein Entwickler führt platform create-service --name my-api --template typescript-api aus, beantwortet 5 Fragen (Service-Name, Team, Datenbank benötigt, öffentlich oder intern), und bekommt ein voll funktionsfähiges Projekt mit CI/CD, Monitoring und Deployment-Manifesten. Erstes Deployment in 15 Minuten.

Golden-Path-Prinzipien

Was einen guten vs. schlechten Golden Path ausmacht

Self-Service-Infrastruktur

Entwickler sollten kein Ticket erstellen müssen, um eine Datenbank, eine Redis-Instanz oder einen neuen Kubernetes-Namespace zu bekommen. Self-Service bedeutet, dass sie provisionieren können, was sie brauchen, über eine UI, CLI oder API.

// Platform CLI: PostgreSQL-Datenbank provisionieren
// $ platform db create --name my-api-db --size small --env staging
interface DatabaseRequest {
    name: string;
    size: 'small' | 'medium' | 'large';  // Meinungsstark: 3 Größen, keine beliebigen Specs
    environment: 'dev' | 'staging' | 'production';
    team: string;
    backupRetention: number;  // Default: 7 Tage Staging, 30 Tage Production
}

// Hinter den Kulissen: Terraform läuft, erstellt RDS-Instanz,
// speichert Credentials in Secrets Manager, erstellt K8s Secret,
// fügt Monitoring-Dashboard hinzu, benachrichtigt das Team

Was per Self-Service angeboten werden sollte

Die Grenze: Self-Service für Ressourcen, die auf ein Team beschränkt sind. Anfrage-basiert für Ressourcen, die die gesamte Organisation betreffen.

Interne Entwicklerportale

Ein internes Entwicklerportal ist ein Katalog aller Services, ihrer Eigentümer, ihrer APIs, ihrer Runbooks und ihres Gesundheitsstatus. Backstage (von Spotify) ist das bekannteste, aber nicht die einzige Option.

Was ein Portal zeigen sollte

Backstage vs. Alternativen

Für Teams unter 30 Ingenieuren ist Backstage Overkill. Ein gut organisiertes Git-Repository mit README-Dateien, ein gemeinsames Notion-Wiki und eine einfache Service-Katalog-Tabelle decken 80% des Bedarfs ab.

Für Teams über 50 Ingenieure wird das Katalog-Problem real. Services werden erstellt und vergessen. Eigentümer gehen und niemand weiß, wer was wartet. Ein Portal mit Ownership-Tracking und Health-Dashboards wird essenziell.

Das Dokumentationsproblem

Niemand liest dein Wiki. Das ist kein Menschenproblem. Es ist ein Standortproblem. Dokumentation, die getrennt vom Code lebt, den sie beschreibt, wird innerhalb von Wochen veraltet.

Dokumentation, die funktioniert

Architecture Decision Records (ADRs)

Jede signifikante technische Entscheidung bekommt einen ADR:

# ADR-003: PostgreSQL als primäre Datenbank verwenden

## Status: Akzeptiert

## Kontext
Wir brauchen eine Datenbank für den neuen Service. Betrachtete Optionen: PostgreSQL, MySQL, DynamoDB.

## Entscheidung
PostgreSQL 15 über das Self-Service-Datenbank-Provisioning der Plattform.

## Konsequenzen
- Standard-Tooling (Backups, Monitoring, Migrationen) funktioniert out of the box
- Team braucht keine DynamoDB-Expertise
- Etwas höhere Latenz als DynamoDB für Key-Value-Zugriffsmuster (akzeptabel)

ADRs verhindern, dass dieselben Entscheidungen immer wieder diskutiert werden. Wenn ein neues Teammitglied fragt "Warum PostgreSQL?", steht die Antwort im Repo, nicht im Kopf von jemandem.

Developer Experience messen

Wenn du in eine Plattform investierst, miss, ob sie tatsächlich hilft:

Die ersten vier sind DORA-Metriken. Die letzten drei sind plattformspezifisch. Tracke alle. Wenn sich Time-to-first-deploy verbessert, aber die Entwicklerzufriedenheit sinkt, fügt die Plattform Komplexität hinzu, ohne Wert zu liefern.

Wann Platform Engineering Overhead ist

Platform Engineering ist nicht kostenlos. Ein Platform Team kostet 2-5 Vollzeit-Ingenieure. Golden Paths brauchen Wartung. Self-Service-Tools brauchen Entwicklung und Support. Ein Portal braucht Inhalte.

Bau keine Plattform, wenn

• Dein Team unter 20 Ingenieuren hat (der Overhead übersteigt den Nutzen)
• Du weniger als 5 Services hast (nicht genug Standardisierungspotenzial)
• Du ein Startup bist, das vielleicht pivotiert (die Plattform wäre verschwendet)
• Dein Engineering-Prozess bereits schnell ist (wenn Time-to-Deploy bereits bei 30 Minuten liegt, brauchst du kein Platform Team, um es zu verbessern)

Bau eine Plattform, wenn

• Du 50+ Ingenieure hast, die 10+ Services deployen
• Das Erstellen eines neuen Services mehr als einen Tag dauert
• Teams dieselben Infrastrukturmuster immer wieder neu erfinden
• On-Call schmerzhaft ist, weil jeder Service ein anderes Monitoring hat
• Die Entwicklerzufriedenheit niedrig ist wegen Infrastruktur-Reibung

Die Minimal-Plattform für ein 30-50 Personen-Team:

1. Ein Golden-Path-Template (der häufigste Service-Typ)
2. CI/CD-Pipeline-Template (geteilt, parametrisiert)
3. Standard-Monitoring (Grafana-Dashboards automatisch provisioniert)
4. Service-Katalog (selbst wenn es nur eine Tabelle ist)
5. Eine Seite Platform-Guide ("Wie erstelle ich einen neuen Service")

Das war's. Kein Backstage, kein eigenes Portal, keine Self-Service-Infrastruktur. Nur Templates und Standards. Füge Komplexität hinzu, wenn das Team den einfachen Ansatz herauswächst.

Häufige Fehler

1. Eine Plattform bauen, bevor du Standardisierung hast. Wenn jeder Service eine andere Sprache, ein anderes Framework und eine andere Deployment-Methode nutzt, kann eine Plattform nicht helfen. Erst standardisieren, dann plattformisieren.

2. Backstage vor 50 Ingenieuren. Backstage ist mächtig, aber komplex. Für kleinere Teams übersteigen die Setup- und Wartungskosten den Nutzen.

3. Golden Paths, die nie aktualisiert werden. Ein Template von vor 2 Jahren mit veralteten Abhängigkeiten und veralteten Mustern schadet mehr als es nützt. Warte es wie ein Produkt.

4. Alles per Self-Service. IAM-Rollen und Netzwerkänderungen sollten nicht per Self-Service gehen. Der Blast Radius eines Fehlers ist zu groß.

5. Aktivität messen, nicht Ergebnisse. "Wir haben 15 Platform-Features gebaut" ist kein Erfolg. "Time-to-first-deploy sank von 2 Tagen auf 30 Minuten" ist Erfolg.

6. Entwicklerzufriedenheit ignorieren. Eine Plattform, die Entwickler in Muster zwingt, die sie hassen, wird umgangen. Sprich regelmäßig mit deinen Nutzern (den Entwicklern).

7. Keine Dokumentation. Eine Self-Service-Plattform ohne Dokumentation ist nur eine andere Art von Black Box.

Wichtigste Erkenntnisse

• Platform Engineering ist kein Tool, es ist ein Ansatz. Baue interne Tools, die Entwickler produktiv machen, ohne dass sie Infrastruktur-Expertise brauchen. Der Golden Path ist das Kernprodukt.

• Time to first deploy ist die Schlüsselmetrik. Wenn ein Entwickler in 15 Minuten von der Idee zum laufenden Service kommt, funktioniert die Plattform. Wenn es 2 Tage dauert, nicht.

• Fang einfach an. Ein Golden Path, ein CI/CD-Template, Standard-Monitoring. Füge Komplexität hinzu, wenn der einfache Ansatz nicht mehr reicht. Die meisten Teams unter 30 Ingenieuren brauchen kein Backstage.

• Dokumentation lebt beim Code. Auto-generierte API-Docs, Runbooks im Repo, ADRs für Entscheidungen. Wiki-Seiten werden veraltet. In-Repo-Docs bleiben aktuell.

• Miss Ergebnisse, nicht Aktivität. DORA-Metriken plus Entwicklerzufriedenheit. Wenn sich die Zahlen nicht verbessern, funktioniert die Plattform-Investition nicht.

• Das Platform Team ist ein Produktteam. Ihre Nutzer sind Entwickler. Ihr Produkt ist die interne Plattform. Sie brauchen Feedback-Loops, User Research und Iteration, genau wie jedes Produktteam.

Wir bauen interne Plattformen und Developer Tooling als Teil unserer Cloud-Services und Consulting-Praxis. Wenn du Hilfe bei der Platform-Engineering-Strategie brauchst, sprich mit unserem Team oder fordere ein Angebot an. Schau dir auch unsere Methodenseite an, um zu erfahren, wie wir Engineering-Kultur angehen.