Platform Engineering hat sich von einem Gartner-Schlagwort zur operativen Realität entwickelt. Bis 2026 werden 80 % der großen Software-Engineering-Organisationen dedizierte Plattform-Teams haben, die wiederverwendbare Services, Komponenten und Tools für die Anwendungsbereitstellung bereitstellen. Die erfolgreichen Organisationen bauen nicht einfach nur Infrastruktur — sie bauen Produkte, die ihre eigenen Entwickler tatsächlich nutzen wollen.
Der Unterschied zwischen einer erfolgreichen Internal Developer Platform und einem teuren Regal-Projekt, das niemand nutzt, läuft auf eines hinaus: Behandeln Sie Ihre Plattform als Produkt mit Entwicklern als Kunden. Das bedeutet, Akzeptanz zu messen (nicht nur Nutzung), freiwillige Übernahme durch Teams zu gewinnen und kontinuierlich Reibungsverluste im Entwickler-Workflow zu reduzieren.
Dieser Leitfaden behandelt die praktische Architektur des modernen Platform Engineering — was Sie aufbauen sollten, welche Tools Sie verwenden, wie Sie Ihr Team strukturieren und wie Sie messen, ob Ihre Plattform tatsächlich funktioniert.
Warum Platform Engineering existiert
Das Problem, das Platform Engineering löst, ist einfach: Wenn Organisationen skalieren, wächst die Kluft zwischen dem, was Entwickler tun müssen (Features ausliefern) und dem, womit sie sich beschäftigen müssen (Infrastruktur, Sicherheit, Compliance, Observability), bis die Produktivität unter dem Gewicht der operativen Komplexität zusammenbricht.
Ohne eine Plattform sieht ein typischer Entwickler-Workflow für die Bereitstellung eines neuen Service so aus:
- Eine Laufzeitumgebung wählen (Container? Serverless? VM?)
- Ein Dockerfile schreiben (hoffentlich sicher)
- CI/CD einrichten (Pipelines, Secrets, Umgebungen konfigurieren)
- Infrastruktur bereitstellen (Terraform? CloudFormation? In einer Konsole herumklicken?)
- Netzwerk konfigurieren (Ingress, Load Balancer, DNS, TLS-Zertifikate)
- Monitoring einrichten (Welches Tool? Wohin gehen die Logs? Welche Alerts?)
- Secrets-Management handhaben (Vault? Umgebungsvariablen? Auf das Beste hoffen?)
- Sicherheitsanforderungen adressieren (Scanning, Policies, Compliance-Checks)
- Dokumentation schreiben (vielleicht)
- Durch einen Change-Review-Prozess kommen (irgendwann)
Jeder Schritt beinhaltet Entscheidungen, die die meisten Anwendungsentwickler nicht treffen müssen sollten. Die Aufgabe des Plattform-Teams ist es, diese Entscheidungen in Self-Service-Fähigkeiten zu kodieren, die Entwicklern erlauben, von „Ich habe Code" zu „Er läuft in Produktion" zu springen, mit Leitplanken, die sicherstellen, dass Sicherheit, Compliance und Betriebsstandards automatisch eingehalten werden.
Mit einer Plattform wird der gleiche Workflow zu:
- Eine Vorlage aus dem Service-Katalog auswählen
- Die Lücken ausfüllen (Service-Name, Team, Tier)
- Code pushen
- Es ist bereitgestellt mit CI/CD, Monitoring, Netzwerk und Sicherheit integriert
Das ist das Wertversprechen: Eine kuratierte, Self-Service-Erfahrung, die die kognitive Belastung reduziert und gleichzeitig organisatorische Standards durchsetzt.
Architektur einer Internal Developer Platform
Eine gut strukturierte IDP hat fünf Schichten, von denen jede einem bestimmten Zweck dient:
Schicht 1: Entwicklerportal (Die Schnittstelle)
Das Entwicklerportal ist das Schaufenster Ihrer Plattform. Hier entdecken Entwickler Services, lesen Dokumentation, erstellen neue Projekte und sehen den Status ihrer Deployments. Backstage, ursprünglich von Spotify entwickelt und jetzt ein CNCF-Inkubationsprojekt, hält etwa 89 % Marktanteil unter Organisationen, die eine IDP eingeführt haben.
Das Portal bietet:
- Software-Katalog: Ein Verzeichnis aller Services, APIs, Bibliotheken und Infrastrukturkomponenten, die von jedem Team verwaltet werden.
- Templates (Golden Paths): Vorkonfigurierte Projektvorlagen, die die Best Practices Ihrer Organisation kodieren.
- TechDocs: Documentation-as-Code, direkt im Portal gerendert.
- Plugin-Ökosystem: Erweiterbare Integrationen mit CI/CD, Monitoring, Cloud-Anbietern und Sicherheitstools.
# catalog-info.yaml — Einen Service in Backstage registrieren
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:.
pagerduty.com/service-id: P1A2B3C
tags:
- python
- payments
- tier-1
links:
- url: https://grafana.internal/d/payments
title: Grafana Dashboard
icon: dashboard
spec:
type: service
lifecycle: production
owner: team-payments
system: billing
providesApis:
- payments-api
dependsOn:
- component:user-service
- resource:payments-db
Schicht 2: Golden Paths (Gepflasterte Wege)
Golden Paths sind das wirkungsvollste Feature einer Plattform. Sie sind meinungsstarke, vorkonfigurierte Wege durch Ihre Infrastruktur, die Entscheidungen kodieren, damit Entwickler sie nicht treffen müssen. Das Schlüsselwort ist „meinungsstark" — ein Golden Path sagt „so bauen wir einen Python-API-Service in diesem Unternehmen" und liefert alles, was benötigt wird, um von Null zur Produktion zu gelangen.
Ein guter Golden Path beinhaltet:
- Projektgerüst mit Ihrer Standard-Verzeichnisstruktur
- Vorkonfigurierte CI/CD-Pipeline
- Dockerfile nach Ihren Sicherheitsstandards gebaut
- Kubernetes-Manifeste oder Deployment-Konfiguration
- Monitoring-Dashboards und Alert-Regeln
- Sicherheits-Scanning in die Pipeline integriert
- Dokumentationsvorlage
# template.yaml — Backstage Software Template für eine Python-API
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: python-api-service
title: Python API Service
description: |
Create a production-ready Python API service with FastAPI,
Docker, CI/CD, monitoring, and security scanning pre-configured.
tags:
- python
- fastapi
- recommended
spec:
owner: team-platform
type: service
parameters:
- title: Service Information
required:
- name
- owner
- description
properties:
name:
title: Service Name
type: string
pattern: '^[a-z][a-z0-9-]*$'
description: Lowercase alphanumeric with hyphens
description:
title: Description
type: string
maxLength: 200
owner:
title: Owner Team
type: string
ui:field: OwnerPicker
ui:options:
allowedKinds: [Group]
- title: Infrastructure
properties:
tier:
title: Service Tier
type: string
enum: [tier-1, tier-2, tier-3]
enumNames:
- "Tier 1 — Business critical (99.9% SLA)"
- "Tier 2 — Important (99.5% SLA)"
- "Tier 3 — Internal tooling (best effort)"
default: tier-2
database:
title: Database
type: string
enum: [none, postgresql, redis, both]
default: none
steps:
- id: scaffold
name: Generate Project
action: fetch:template
input:
url: ./skeleton
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
description: ${{ parameters.description }}
tier: ${{ parameters.tier }}
database: ${{ parameters.database }}
- id: publish
name: Create Repository
action: publish:github
input:
repoUrl: github.com?owner=myorg&repo=${{ parameters.name }}
description: ${{ parameters.description }}
defaultBranch: main
protectDefaultBranch: true
requireCodeOwnerReviews: true
- id: register
name: Register in Catalog
action: catalog:register
input:
repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
catalogInfoPath: /catalog-info.yaml
- id: create-argocd-app
name: Setup Deployment
action: argocd:create-application
input:
appName: ${{ parameters.name }}
repoUrl: ${{ steps.publish.output.remoteUrl }}
path: k8s/overlays/production
Schicht 3: Infrastruktur-Orchestrierung
Hinter dem Portal und den Templates benötigen Sie eine Schicht, die tatsächlich Infrastruktur bereitstellt und verwaltet. Im Jahr 2026 ist der Basis-Stack:
- Kubernetes für Container-Orchestrierung (EKS, GKE, AKS oder selbstverwaltet)
- Terraform oder OpenTofu für Infrastruktur-Bereitstellung
- ArgoCD oder Flux für GitOps-basiertes Deployment
- Crossplane für Kubernetes-natives Infrastrukturmanagement
Crossplane verdient besondere Aufmerksamkeit, weil es Plattform-Teams ermöglicht, Infrastruktur als Kubernetes Custom Resources bereitzustellen. Anstatt dass Entwickler Terraform schreiben, reichen sie ein YAML-Manifest ein, das eine Datenbank anfordert, und Crossplane stellt sie über die API des Cloud-Anbieters bereit.
# Eine PostgreSQL-Datenbank über Crossplane anfordern
apiVersion: database.platform.example.com/v1alpha1
kind: PostgreSQLInstance
metadata:
name: payment-service-db
namespace: team-payments
spec:
parameters:
storageGB: 50
version: "16"
tier: production # wird auf die entsprechende Instanzklasse abgebildet
backup:
enabled: true
retentionDays: 30
compositionRef:
name: aws-postgresql # Das Plattform-Team verwaltet diese Composition
writeConnectionSecretToRef:
name: payment-db-credentials
namespace: team-payments
Der Entwickler fordert eine Datenbank an, indem er beschreibt, was er braucht. Die Crossplane-Composition des Plattform-Teams behandelt das Wie — welcher Cloud-Anbieter, welcher Instanztyp, welche Netzwerkkonfiguration, welche Backup-Richtlinie. Wenn die Organisation von AWS zu GCP migriert, aktualisiert das Plattform-Team die Composition und die Entwickler ändern keine einzige Zeile.
Schicht 4: CI/CD und Auslieferung
Die Auslieferungsschicht automatisiert den Weg vom Code-Commit zum Produktions-Deployment. Eine moderne Plattform bietet standardisierte Pipelines, die Teams erben, anstatt sie von Grund auf zu erstellen.
# .github/workflows/platform-pipeline.yaml
# Vom Golden Path Template geerbt — Teams passen über Konfiguration an, nicht über Pipeline-Code
name: Platform Standard Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
quality-gates:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Security Scan (SAST)
uses: platform/security-scan@v3
with:
severity-threshold: high
fail-on-vulnerability: true
- name: Dependency Audit
uses: platform/dependency-audit@v2
with:
policy: organizational-standards
- name: Unit Tests
run: make test
- name: Container Build & Scan
uses: platform/container-build@v4
with:
registry: registry.internal
scan-policy: strict
deploy-staging:
needs: quality-gates
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- name: Deploy to Staging
uses: platform/gitops-deploy@v3
with:
environment: staging
auto-promote: false # Manuelle Promotion zur Produktion erforderlich
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment: production # Genehmigung erforderlich
steps:
- name: Deploy to Production
uses: platform/gitops-deploy@v3
with:
environment: production
strategy: canary
canary-percentage: 10
promotion-criteria:
error-rate-threshold: 0.1%
latency-p99-threshold: 500ms
Schicht 5: Observability und Feedback
Die letzte Schicht schließt die Feedback-Schleife. Jeder Service, der über die Plattform bereitgestellt wird, erhält automatisch Monitoring, Logging und Alerting, konfiguriert nach organisatorischen Standards.
# Automatisch vom Golden Path Template generiert
# monitoring/alerts.yaml
groups:
- name: payment-service-slo
rules:
- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{service="payment-service",status=~"5.."}[5m]))
/
sum(rate(http_requests_total{service="payment-service"}[5m]))
> 0.001
for: 5m
labels:
severity: critical
tier: "1"
team: payments
annotations:
summary: "Fehlerrate des Payment-Service überschreitet 0,1%"
runbook: "https://portal.internal/docs/runbooks/payment-service/high-error-rate"
- alert: HighLatency
expr: |
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket{service="payment-service"}[5m])) by (le)
) > 0.5
for: 5m
labels:
severity: warning
tier: "1"
team: payments
Plattformerfolg messen
Die entscheidende Verschiebung in der Platform-Engineering-Reife ist der Wechsel vom Messen der Nutzung zum Messen der Akzeptanz. Nutzung sagt Ihnen, dass Menschen mit der Plattform interagieren; Akzeptanz sagt Ihnen, dass sie sich dafür entscheiden, sie zu nutzen, wenn sie Alternativen haben.
Schlüsselmetriken
Akzeptanzrate: Welcher Prozentsatz neuer Services wird über die Golden Paths der Plattform erstellt im Vergleich zu manuell? Ziel: >80 % innerhalb von 12 Monaten.
Zeit bis zum ersten Deployment: Wie lange dauert es, bis ein neuer Entwickler seine erste Änderung in die Produktion deployt? Mit einer ausgereiften Plattform sollte dies unter 1 Tag liegen (einschließlich Onboarding).
Plattform-Umgehungsrate: Wie oft arbeiten Teams um die Plattform herum? Jede Umgehung ist ein Signal, dass die Plattform einen echten Bedarf nicht erfüllt. Verfolgen Sie Ausnahmeanträge.
Reduktion der kognitiven Belastung: Befragen Sie Entwickler vierteljährlich. Fragen Sie: „Wie viel Ihrer Zeit wird für Infrastruktur im Vergleich zu Feature-Arbeit aufgewendet?" Der Trend ist wichtiger als die absolute Zahl.
Mittlere Wiederherstellungszeit (MTTR): Services, die auf der Plattform aufgebaut sind, sollten sich schneller von Vorfällen erholen, weil sie standardisiertes Monitoring, Runbooks und Deployment-Rollback-Mechanismen haben.
# platform_metrics.py — Plattform-Gesundheitsmetriken verfolgen und berichten
from dataclasses import dataclass
from datetime import datetime, timedelta
@dataclass
class PlatformMetrics:
total_services: int
platform_services: int # Über Golden Paths erstellt
manual_services: int # Außerhalb der Plattform erstellt
bypass_requests: int # In diesem Quartal angefragte Ausnahmen
avg_first_deploy_hours: float
developer_satisfaction: float # Skala 1-10 aus Umfrage
@property
def adoption_rate(self) -> float:
"""Prozentsatz der Services, die die Plattform nutzen."""
if self.total_services == 0:
return 0.0
return (self.platform_services / self.total_services) * 100
@property
def bypass_rate(self) -> float:
"""Wie oft Teams um die Plattform herum arbeiten."""
if self.total_services == 0:
return 0.0
return (self.bypass_requests / self.total_services) * 100
def health_report(self) -> str:
"""Zusammenfassung der Plattform-Gesundheit generieren."""
status = "healthy" if self.adoption_rate > 80 else "needs attention"
return (
f"Platform Health: {status}\n"
f" Adoption Rate: {self.adoption_rate:.1f}%\n"
f" Bypass Rate: {self.bypass_rate:.1f}%\n"
f" Avg First Deploy: {self.avg_first_deploy_hours:.1f} hours\n"
f" Developer Satisfaction: {self.developer_satisfaction:.1f}/10\n"
f" Total Services: {self.total_services} "
f"({self.platform_services} platform, "
f"{self.manual_services} manual)"
)
Strukturierung des Plattform-Teams
Ein Plattform-Team ist kein Infrastruktur-Team mit neuem Namen. Die Unterscheidung ist wichtig, weil sie alles von der Einstellung bis zur Priorisierung beeinflusst.
Infrastruktur-Teams bauen und warten Systeme. Ihre Kunden sind Maschinen. Ihre Erfolgsmetrik ist Verfügbarkeit.
Plattform-Teams bauen Produkte für Entwickler. Ihre Kunden sind Menschen. Ihre Erfolgsmetrik ist Akzeptanz. Das bedeutet, Plattform-Engineers brauchen Produktdenken, User-Research-Fähigkeiten und die Fähigkeit, „Nein" zu Features zu sagen, die Komplexität ohne proportionalen Wert hinzufügen.
Eine typische Plattform-Team-Struktur für eine mittelgroße Organisation (200-500 Entwickler):
- Platform Product Manager (1): Verantwortet die Roadmap, priorisiert basierend auf Entwickler-Feedback, verfolgt Akzeptanzmetriken.
- Platform Engineers (3-5): Bauen und warten Plattformkomponenten — Backstage-Plugins, Golden-Path-Templates, Crossplane-Compositions, CI/CD-Pipeline-Templates.
- Developer Advocates (1-2): Onboarden Teams, schreiben Dokumentation, führen interne Workshops durch, sammeln Feedback.
- SRE/Reliability (1-2): Stellen sicher, dass die Plattform selbst zuverlässig ist, verwalten Kubernetes-Cluster, handhaben Incident Response für die Plattform-Infrastruktur.
Häufige Fehler
Bauen ohne mit Entwicklern zu sprechen. Der Hauptgrund, warum Plattformen scheitern, ist, dass das Plattform-Team das baut, was es denkt, dass Entwickler brauchen, anstatt das, was Entwickler tatsächlich brauchen. Interviewen Sie Ihre Nutzer. Beobachten Sie sie bei der Arbeit. Messen Sie, wo sie Zeit verlieren.
Vorschreiben statt Akzeptanz verdienen. Wenn Sie Teams auf Ihre Plattform zwingen müssen, ist Ihre Plattform nicht gut genug. Die besten Plattformen gewinnen durch Entwicklererfahrung — sie sind schneller, einfacher und zuverlässiger als die Alternative.
Zu früh über-abstrahieren. Beginnen Sie mit einem Golden Path für Ihren häufigsten Service-Typ. Machen Sie es richtig. Dann erweitern Sie. Plattformen, die versuchen, vom ersten Tag an jeden möglichen Anwendungsfall zu unterstützen, unterstützen am Ende keinen davon gut.
Den Notausgang ignorieren. Entwickler brauchen die Möglichkeit, anzupassen, wenn der Golden Path nicht passt. Wenn Ihre Plattform ein ummauerte Garten ohne Ausgänge ist, werden Teams sie komplett verlassen, anstatt einzelne Einschränkungen zu umgehen.
Es als einmaliges Projekt behandeln. Eine Plattform ist ein Produkt. Sie braucht kontinuierliche Investition, Feedback-Schleifen und Iteration. Das Team, das die Plattform gestartet hat, sollte sie ein Jahr später immer noch verbessern.
Erste Schritte
Wenn Sie bei Null anfangen, hier ist eine praktische Abfolge:
Monat 1-2: Interviewen Sie 10 Entwicklungsteams. Erfassen Sie ihren Deployment-Workflow von Anfang bis Ende. Identifizieren Sie die drei größten Reibungspunkte. Richten Sie Backstage mit einem grundlegenden Software-Katalog ein.
Monat 3-4: Bauen Sie Ihren ersten Golden Path für den häufigsten Service-Typ in Ihrer Organisation (wahrscheinlich eine REST-API). Schließen Sie CI/CD, Container-Build, Kubernetes-Deployment und grundlegendes Monitoring ein. Deployen Sie ihn mit einem freiwilligen Team.
Monat 5-6: Iterieren Sie basierend auf dem Feedback des Pilotteams. Fügen Sie TechDocs-Integration hinzu. Bauen Sie Ihren zweiten Golden Path für den zweithäufigsten Service-Typ. Onboarden Sie 3-5 weitere Teams.
Monat 7-12: Skalieren Sie die Akzeptanz. Fügen Sie Crossplane für Self-Service-Infrastruktur hinzu. Bauen Sie Dashboards für Plattform-Metriken. Etablieren Sie eine interne Entwickler-Community rund um die Plattform. Zielen Sie auf 50 % Akzeptanz der Golden Paths für neue Services.
Die Organisationen, die 2026 den größten Wert aus Platform Engineering ziehen, teilen ein gemeinsames Merkmal: Sie behandeln ihre Plattform als das wichtigste Produkt, das sie bauen — weil jedes andere Produkt davon abhängt.