Was macht ein Platform Engineer wirklich?

In Stellenanzeigen steht oft „Platform Engineer”, aber wenn man genau hinsieht, sucht die Firma eigentlich einen DevOps-Allrounder oder einen Kubernetes-Admin. Die Rolle kann das zwar beinhalten, aber das eigentliche Ziel ist ein anderes: Entwickler sollen ihre Software schneller und sicherer in Produktion bringen, ohne dass jedes Team die komplette Infrastruktur dafür neu erfinden muss.

Wenn du in einem Interview (oder intern) erklären musst, was du eigentlich tust, fang am besten mit dem Problem an, das gelöst werden soll — nicht mit Helm-Charts oder Terraform-Modulen.

Was passiert, wenn Unternehmen wachsen?

Am Anfang baut sich jedes Team seine eigene kleine Welt: eigene CI-Pipelines, eigene Cluster-Zugänge, eigenes Monitoring. Bei drei Teams ist das okay. Bei fünfzehn Teams existieren plötzlich acht verschiedene Deployment-Verfahren, niemand weiß, welche Images eigentlich in Produktion laufen, Security wird zur Lotterie — und das eine zentrale Ops-Team erstickt in Tickets, weil jemand einen Port freigeschaltet haben möchte. Die Wartezeit auf eine neue Umgebung liegt bei zwei Wochen, und die besten Entwickler verbringen ihre Zeit mit YAML-Debugging statt mit Features.

Genau da lohnt sich ein Platform-Team. Ihr baut ein internes Produkt für die anderen Teams, keinen Fulfillment-Schalter für Jira-Tickets. Der Fachbegriff dafür ist Cognitive Load: Anwendungsteams sollen über ihre Domäne nachdenken, nicht über Ingress-Annotations. Platform Engineering ist die institutionalisierte Antwort auf diese Skalierungsprobleme — nicht einfach „noch ein DevOps-Team”.

DevOps, SRE, Platform — wo ist der Unterschied?

Machen wir es kurz:

• DevOps: Baut die Delivery-Pipeline und kümmert sich um das Tooling, oft für genau ein Produkt oder eine Produktlinie.
• SRE (Site Reliability Engineering): Fokussiert sich auf Reliability, SLOs und Incident Response für laufende Services.
• Platform Engineering: Baut Shared Capabilities als Produkt für viele verschiedene Teams. Das umfasst Compute, Deployments, Observability, Secrets Management und Self-Service-Portale.

Natürlich gibt es in der Praxis riesige Überlappungen. In einem Startup macht oft eine Person alles gleichzeitig. Im Team-Topologies-Vokabular ist die Unterscheidung trotzdem sauber: das Platform-Team ist ein Platform Team, das Stream-aligned Teams (die Produktteams) bedient — und der präferierte Interaktionsmodus ist X-as-a-Service, nicht Hand-Holding. Im Interview solltest du klarmachen, dass du diese Produkt-Perspektive hast: Du denkst in Adoption und Developer Experience, nicht in abgearbeiteten Tickets.

Was eine IDP wirklich liefert

Eine Internal Developer Platform (IDP) bündelt genau die Capabilities, die jedes Team braucht:

• Compute: Kubernetes-Namespaces, vClusters, Autoscaling.
• Delivery: CI-Pipelines, GitOps, Artifact Registries.
• Observability: Metrics, Logs, Traces als fertiger Service.
• Security: Vault, Policy-as-Code, Supply Chain Security.
• Self-Service: Portale, Templates und gute Dokumentation.

Ihr seid Enabler, keine Gatekeeper. Das Konzept heißt: Golden Path plus dokumentierter Escape Hatch. Es heißt nicht „wir verbieten alles” und genauso wenig „jeder macht, was er will”.

Wie sieht ein Golden Path konkret aus?

Ein gutes Beispiel: Ein Entwickler klickt in Backstage auf ein Template. Das erstellt automatisch ein Repo mit CI-Pipeline, eine Argo CD Application, baut Observability-Dashboards direkt mit ein und setzt eine NetworkPolicy, die standardmäßig erstmal dichtmacht, aber über eine Allowlist geöffnet werden kann. Das Team deployt in Stunden, nicht in Wochen — und das Deployment ist ab Tag eins compliant, ohne dass jemand eine Security-Checkliste abarbeiten musste. Das ist der eigentliche Trick: der sichere Weg ist auch der bequemste.

Der Escape Hatch (Notausgang): Ein Machine-Learning-Team braucht unbedingt einen speziellen GPU-Pool. Das geht in Ordnung, erfordert aber ein Architecture Review, hat eine begrenzte Laufzeit und wird nicht heimlich an euch vorbei gebaut. Ein Golden Path ohne Escape Hatch erzeugt Schatten-IT — ein Escape Hatch ohne Review erzeugt das Chaos, das ihr gerade abgeschafft habt.

Metriken, die nicht peinlich sind

Erfolg misst man im Platform Engineering nicht an „Wir haben 200 Helm Releases deployed”. Niemand interessiert sich für eure Release-Zahlen, wenn die Entwickler trotzdem unglücklich sind.

Besser sind DORA-Metriken (Deploy-Frequenz, Lead Time, Change Failure Rate, MTTR) für die gesamte Org oder pro Team. Oder die „Time-to-First-Deploy” für neue Teams und die Adoption-Rate der Plattform — denn eine interne Plattform, die niemand freiwillig nutzt, ist gescheitert, egal wie elegant sie gebaut ist. Dazu ehrlich gemessene Developer Satisfaction, per regelmäßiger Umfrage, nicht per Bauchgefühl. „Unser Onboarding dauert jetzt zwei Tage statt zwei Wochen” — das ist ein Erfolg, den jeder versteht, vom Entwickler bis zum CFO.

Die berüchtigte IDP-Interview-Frage

„Wir haben fünfzig Teams — was baust du als Erstes?”

Die richtige Antwort ist: Nicht alles. Erst kartierst du die Developer Journey und findest den größten Schmerz — oft sind das Deployments oder fehlende Umgebungen, nicht das, was technisch am spannendsten wäre. Dann wählst du ein MVP (häufig Deployments + Observability), setzt Guardrails wie Policies und Quotas, und misst die Adoption mit einem Pilot-Team, bevor du breit ausrollst. Namespace-Isolation reicht für den Anfang oft völlig aus, du musst nicht direkt fünfzig Cluster hochziehen.

Wer das so erzählt, klingt wie jemand, der schon mal eine Plattform gebaut hat — oder der zumindest verstanden hat, worum es wirklich geht. Wie du den Case im Detail durchspielst, zeigt System Design: Internal Developer Platform.

Einstieg gefällig? Schau in den Pfad Platform Engineer. Mehr Interview-Tipps gibt’s hier: Interview-Vorbereitung.