Platform Engineer: Markt

Stelle

eine offene Stelle, die das Qualitäts-Gate passiert hat und mindestens zwei Technologien nennt

Beobachteter Kandidat

ein Kandidat, dessen Stack diese Technologie enthält; ein Aggregat — kein einziger Datensatz verlässt den Perimeter

Matchbarer Kandidat

noch nicht gezählt

Fenster

Stellen, die zum Zeitpunkt der Erstellung des Snapshots offen waren

Junior — selten (typischer Einstieg: DevOps Middle / Backend Middle + Interesse an internem Tooling). Der Sprung Junior → Middle — nach der ersten End-to-End-Einführung einer IDP-Fähigkeit (z. B. Backstage Software Templates für das Scaffolding neuer Services). Middle → Senior — teamübergreifende Plattformverantwortung + Verbesserung von DX-Kennzahlen (z. B. die mittlere Time to First Deploy von 2 Wochen auf 2 Tage senken). Senior → Staff / Principal — organisationsweite IDP-Architektur + teamübergreifende Platform-as-Product-Strategie. Karriereweg: DevOps Middle / Backend Middle (2-3 Jahre) + Interesse → Platform Engineer Junior (1-2 Jahre) → Middle (2-3 Jahre) → Senior → entweder Platform Architect, Spezialisierung als DX Engineer oder Engineering Manager (Platform-Team).

Top 5: devops, cloud, agile, graphql, azure. IDP-Tools (Internal Developer Platform): Backstage (Open Source von Spotify — dominiert 2026 — CNCF Incubating; der größte Stellenmarkt) — nötig sind React + TypeScript (Anpassung des Frontends) + Node.js (Backend-Plugins) + Entitätsmodell von Backstage + Software Catalog + TechDocs + Software Templates + Kubernetes-Plugin. Port (kommerziell — beste UX 2026 — wächst als Konkurrent von Backstage schnell) — einfacher anzupassen, Port-spezifisches Schema. Cortex (Alternative — Fokus auf Service-Katalog). Humanitec (fokussiert auf Plattform-Orchestrierung — Muster für automatisches Deployment). OpsLevel, Configure8. Self-Service-Templates: Backstage Software Templates (Integration mit cookiecutter) / Port Actions / eigenes CLI-Scaffolding (Yeoman / Plop / eigenes Go-CLI). Service-Katalog: Erfassung aller Dienste + Ownership + Abhängigkeiten + Reifegradbewertung (Backstage Software Catalog / Port / OpsLevel). Kubernetes-Ökosystem in der Tiefe: Fundament der Plattform — Crossplane (K8s-natives IaC, anbieterunabhängig — am besten für Plattformabstraktionen), Argo CD (GitOps-Fundament), Tekton (Pipeline-Plattform), Knative (Serverless-Plattform). Plattformabstraktionen: Crossplane Compositions (typisierte Abstraktionen von Cloud-Ressourcen — Beispiel: „Postgres bereitstellen“ = ein einziger API-Aufruf, der sich in RDS + IAM-Rolle + Secret + Netzwerk entfaltet), Terraform-Module + Spacelift / Atlantis (verwaltetes IaC), Kratix (Platform-as-Product-Framework — interessanter neuerer Eintrag 2024+). API-Gateway für Plattform-APIs: Kong / Tyk / Apigee / AWS API Gateway. Entwicklerportal: Backstage UI / Port UI / Cortex UI — eine zentrale Oberfläche für Entwickler (Service-Katalog + Dokumentation + Aktionen + Observability). DX-Metriken (Developer Experience): DORA-Metriken (Deployment Frequency / Lead Time for Changes / Mean Time to Recover / Change Failure Rate — Framework von Google DevOps Research and Assessment), SPACE-Framework, DX-Umfragen (Feedback von Entwicklern). Tools: Sleuth / LinearB / Faros AI / Swarmia / Code Climate Velocity. CI/CD-Plattform: typischerweise Tekton Pipelines (CNCF-nativ) oder Argo Workflows + Argo Events. Observability der Plattform selbst: Metriken zur Plattformnutzung + Kostenzuordnung pro Team + Tracking der DX-Werte. Sprachen: TypeScript primär (Backstage-Plugins) + Go für eigenes Plattform-Tooling + Python für Automatisierung.

DevOps Engineer — Fokus auf CI/CD + Cloud + K8s für ein einzelnes Team / Produkt. Fokus auf Teamebene. Siehe DevOps Engineer (allgemein). SRE (Site Reliability Engineer) — Fokus auf Zuverlässigkeit + SLI / SLO + Rufbereitschaft + Automatisierung zur Reduzierung von Toil. Programmierlastig. Siehe Site Reliability (SRE). Platform Engineer (diese Seite) — Fokus auf eine wiederverwendbare Self-Service-Entwicklerplattform für die gesamte Engineering-Organisation. Denken als internes Produkt: Entwickler = Kunden, Plattformteam = Produktteam. Alltag: Self-Service-Fähigkeiten bauen (z. B. „neuen Service mit einem Klick anlegen“ über Backstage Templates), Service-Katalog + Golden Paths + Paved Roads pflegen. Programmierlastig (TypeScript + Go). Zentraler Unterschied 2026: Platform Engineering ist NICHT einfach umbenanntes DevOps. Echter Unterschied: Plattform-als-Produkt-Denken + Verantwortung für DX-Metriken + Strategien zur teamübergreifenden Adoption + Produktdenken für interne Tools. Unterschied zu SRE: SRE verantwortet die Zuverlässigkeit von Services. Der Platform Engineer verantwortet Zuverlässigkeit + UX der internen Plattform selbst (die andere Teams zum Deployment ihrer Services nutzen). Der Platform Engineer misst Erfolg nicht an der Verfügbarkeit der Infrastruktur, sondern an „wie viele Minuten braucht ein neuer Engineer, um seinen ersten Service zu deployen?“ Unterschied zu DevOps: Ein DevOps Engineer ist typischerweise tief in ein Produktteam eingebettet (CI/CD für ein Produkt). Ein Platform Engineer arbeitet an übergreifender Infrastruktur, die von 10+ Produktteams genutzt wird. Realität der Karriereüberschneidung 2026: 60-70% gemeinsamer Stack. Leichte laterale Wechsel DevOps Senior ↔ Platform Engineer (3-6 Monate). Kleinere Organisationen: eine Person = DevOps und Plattform zugleich. Mittlere / große (50+ Engineers): getrennte Rollen.

Entscheidungsbaum für die IDP-Wahl 2026: 1) Backstage (Open Source von Spotify 2020, CNCF Incubating 2022) — Marktführer 2026 (~60% Anteil). Die größte Nische für Plugin-Entwicklung + eigene Integrationen. Stärken: riesige Community (10K+ Sterne auf GitHub), 130+ offizielle Plugins, vollständig Open Source, Unterstützung polyglotter Services, Software Catalog + TechDocs + Software Templates integriert, Integrationen mit allem. Schwächen: hoher Implementierungsaufwand (typischer Backstage-Rollout — 6-12 Monate Engineering-Investition), erfordert React- + TypeScript-Expertise für Anpassungen, komplexe Plugin-Entwicklung, hoher laufender Wartungsaufwand. Einsatzfall: Unternehmen mit 50+ Engineers + eigenem Plattformteam (3+ Engineers) + Wunsch nach voller Kontrolle + Präferenz für Open Source. 2) Port (kommerzielles israelisches Startup — gegründet 2022, schnelles Wachstum 2024–2026) — führender Herausforderer mit der besten UX. Stärken: deutlich einfachere Implementierung (Setup typischerweise in 1-2 Wochen vs. Backstage 6-12 Monate), deklaratives Blueprint-Modell, schöne UI, integrierte Self-Service Actions, Drag-and-Drop-Service-Builder, native Slack- / Teams-Integrationen. Einsatzfall: Unternehmen mit 20-200 Engineers + Wunsch nach schnellem Nutzen + ohne Investition in ein Plattformteam von 3+ Engineers. 3) Cortex (kommerziell — gegründet 2020, etwas älter als Port) — Fokus auf den Service-Katalog. Stärken: erstklassiges Scoring im Service-Katalog + Reifegrad-Tracking, Fokus auf „Production-Readiness-Scorecards“. Einsatzfall: Organisationen, deren Hauptproblem die Verfolgung der Servicequalität über viele Teams ist. 4) Humanitec (kommerziell — auf Platform Orchestrator fokussiert) — ein anderer Blickwinkel als ein IDP-Portal. Stärken: tiefe K8s-Automatisierung + Deployment-Patterns für mehrere Umgebungen + Trennung von Workloads. Einsatzfall: stark K8s-fokussierte Plattformen, bei denen Deployment-Automatisierung der Hauptbedarf ist (vs. Service Discovery). 5) OpsLevel, Configure8 — Alternativen mit kleinerem Marktanteil. 6) Eigenbau — Unternehmen bauen manchmal ein eigenes minimales IDP (Hugo / Next.js statisch + eigene API-Integrationen). Standardempfehlungen 2026: Großunternehmen / Präferenz für Open Source / eigenes Plattformteam → Backstage. Mid-Market (20-200 Engineers) / schneller Nutzen gewünscht → Port. Qualität des Service-Katalogs als Hauptbedarf → Cortex oder Port. K8s-Deployment-Automatisierung im Vordergrund → Humanitec. Backstage-Markt 2026 — die größte Stellenkategorie, aber Port-Stellen wachsen schnell.

Ja, 38% der Stellen als Platform Engineer sind vollständig remote oder hybrid. Plattformarbeit — cloudbasiert + internes Tooling = ideal für Remote. Outsourcing-Firmen — fast immer remote bei US-Projekten. Russische Unternehmen — hybrid oder remote nach der Probezeit. Internationale Tech-Unternehmen — vollständig remote als Standard. Big Tech — Hybrid als Standard. Contributors im Backstage-Kernteam (Arbeit in der CNCF-Community) — per Definition vollständig remote. Relokations-Hubs: Polen / Deutschland (Platform-Engineering-freundlich) / Kanada / Serbien / Georgien / VAE. Englisch für internationale Platform-Remote-Arbeit — Pflicht (die Platform-Engineering-Community ist englischsprachig — CNCF / Backstage Working Groups / KubeCon Platform Engineering Day).

Platform Engineer (allgemein) — baut + pflegt Plattformfähigkeiten. Verantwortlich für die technische Umsetzung. DX (Developer Experience) Engineer — Teilspezialisierung mit Fokus auf Kennzahlen der Entwicklerproduktivität + Feedbackschleifen mit Entwicklern. Alltag: 1) Entwicklerproduktivität messbar machen (Automatisierung der Messung von DORA- + SPACE-Kennzahlen), 2) Entwicklerumfragen entwerfen + auswerten (qualitatives Feedback), 3) Reibungspunkte im Entwickler-Workflow finden (z. B. „Build dauert 30 Minuten“, „instabile Tests 15%“, „Bereitstellung der Entwicklungsumgebung 2 Stunden“), 4) teamübergreifende Initiativen zur Verringerung der Reibung vorantreiben (teils selbst umsetzen, teils mit anderen Teams koordinieren), 5) Optimierung des Onboardings (Zeit bis zum ersten PR / ersten Deploy für neue Mitarbeiter verkürzen), 6) Entscheidungen zur Standardisierung von Tools (bestimmte IDE / Frameworks / Build-Tools empfehlen / vorschreiben), 7) Strategie für Entwicklerdokumentation (Backstage TechDocs / mkdocs / eigene Lösung). Fähigkeiten: technisch (muss den gesamten Plattform-Stack verstehen) + analytisch (datenbasierte Produktivitätsmessung) + zwischenmenschlich (Entwickler interviewen + echte Probleme herausarbeiten) + Produktdenken (Verbesserungen nach Wirkung priorisieren). Wenig bis mäßig Programmierung. Gehalt: DX Engineer vergleichbar mit Senior Platform Engineer. In US-Tech-Unternehmen wurde der DX Engineer 2024–2026 dank hohem ROI zu einer gefragten Rolle (Entwicklerzeit = teuer). Karrierewahl: Platform Engineer, wenn Sie das Umsetzen von Fähigkeiten mehr reizt als das Messen. DX Engineer, wenn Sie datenbasierte Produktivitätsanalyse + Empathie für die Schmerzpunkte von Entwicklern + teamübergreifender Einfluss reizen. Beides sind legitime Wege ab Senior. Bekannte Stimmen des DX Engineering 2026: Abi Noda (Mitgründer von DX, ehemaliger Research Lead bei GitHub — Autor des Papers zum SPACE-Framework), Lorin Hochstein (Resilience Engineering / Chaos), Charity Majors (Überschneidung von Observability + DX — Honeycomb).

Roadmap: 1) Solide DevOps-Basis — Linux + Docker + Kubernetes (CKA) + IaC (Terraform) + eine Cloud + CI/CD. Platform Engineering baut AUF dem DevOps-Stack auf. 2) Software-Engineering-Fähigkeiten — Backstage und eigene Plattform-Tools sind Software Engineering, angewandt auf Infrastrukturprobleme. Backend-Middle-Niveau in einer Sprache (Go vorrangig für CLI-Tools, TypeScript + React für Backstage). 3) Backstage in der Tiefe — die am besten vermarktbare IDP-Fähigkeit 2026. Ressourcen: Backstage-Dokumentation (backstage.io) + YouTube-Kanal von Backstage + das Buch „Developer Platforms with Backstage“ von Eli Goldberg. Eine Backstage-Instanz auf Ihrer eigenen Infrastruktur aufsetzen. Ein eigenes Plugin erstellen (z. B. ein unternehmensspezifisches Dashboard integrieren). Einen kleinen Fix zum Backstage-Kern beitragen. 4) Crossplane — die zweitbest vermarktbare Plattform-Fähigkeit. Compositions lernen (typisierte Abstraktionen von Cloud-Ressourcen). Crossplane auf einem K8s-Cluster einrichten, eine Composition für „Postgres bereitstellen“ definieren (abstrahiert RDS + IAM + Secrets). 5) ArgoCD beherrschen (von der Plattform deployte Apps + ApplicationSets für Mandantenfähigkeit). 6) Tekton Pipelines — CNCF-Pipeline-Plattform (Alternative zu Jenkins + GitLab CI für plattformnatives CI/CD). 7) DORA-Kennzahlen einrichten — automatisierte Erfassung von Deployment Frequency / Lead Time / MTTR / Change Failure Rate umsetzen (mit Tools — Sleuth / LinearB / Faros AI — oder selbst gebaut). 8) Lektüre zum SPACE-Framework — das Paper „The SPACE of Developer Productivity“ von Forsgren / Storey / Maddila / Zimmermann / Houck / Nagappan (kostenloses PDF). 9) Design des Service-Katalogs — Backstage Software Catalog / Blueprints von Port — Modellierung der Entitäten für Ihre reale Organisationsstruktur. 10) Self-Service-Templates — Backstage Software Templates (basierend auf cookiecutter) — ein Template für einen neuen Microservice erstellen (inklusive K8s-Manifesten + CI/CD + Observability + Eintrag im Service-Katalog). 11) Fortgeschrittenes Pet-Projekt: vollständiger IDP-Aufbau (Backstage + Crossplane + ArgoCD + eigene Software Templates + Dashboard für DORA-Kennzahlen) — als Portfolio dokumentieren. 12) Engagement in der Platform-Engineering-Community: KubeCon Platform Engineering Day (CNCF), Internal-Developer-Platform-Community (internaldeveloperplatform.org), Community platformengineering.org. Pflichtlektüre: „Team Topologies“ von Skelton / Pais (kanonisch, um Plattformteams + Interaktionsmodi zu verstehen), „The Phoenix Project“ von Kim + Fortsetzung „The Unicorn Project“ (Kontext DevOps + Plattform), „Accelerate“ von Forsgren / Humble / Kim (Ursprung der DORA-Kennzahlen), „Developer Platforms with Backstage“ von Goldberg. Kurse: Videos der Backstage Working Group (kostenlos auf YouTube), Lernpfade von internaldeveloperplatform.org, Humanitec Academy (kostenlose Kurse zu Platform Engineering). DevOps Middle / Backend Middle + Interesse → Platform Engineer Junior — 4-10 Monate.

68 active open Platform Engineer positions — growing internal-developer-platform specialisation. Geography: the US, the UK, Poland. The real market is broader thanks to the international remote segment. Time to close a Senior Platform Engineer role — 5-10 weeks (longer than general DevOps due to specialisation + Backstage / Port expertise requirement). Platform Engineering as a category is growing fastest 2024–2026 per DORA / Puppet State of Platform Engineering reports.

Ein Senior Platform Engineer verantwortet den gesamten Zyklus aus IDP-Architektur + DX-Optimierung + technischer Führung. Software Engineering auf Backend-Senior-Niveau: Beherrschung von TypeScript + React (für die Entwicklung von Backstage-Plugins) + Go als Hauptsprache (für eigenes Plattform-Tooling) + Python für Automatisierung. Beherrschung von Backstage in der Tiefe: Erstellen von Plugins (Frontend-React-Komponenten + Backend-Node.js-Plugins), Entitätsmodell des Software Catalog in der Tiefe, fortgeschrittenes Setup von TechDocs, Software Templates fortgeschritten (eigene Yeoman-Generatoren), Catalog Processors für eigene Entitätsquellen, Permission Framework für mandantenfähiges Backstage. Oder gleichwertige Expertise in Port / Cortex als alternatives IDP. Beherrschung von Crossplane: Entwurf von Compositions (typisierte Abstraktionen von Cloud-Ressourcen), bei Bedarf Entwicklung eigener Provider, Muster für Multi-Cloud-Abstraktion. Beherrschung der Kubernetes-Plattform: ArgoCD ApplicationSets für Mandantenfähigkeit + mehrere Cluster, Tekton Pipelines fortgeschritten, Knative für ein Serverless-Plattformangebot. Entwurf von Self-Service-Vorlagen: Beherrschung des Scaffoldings (Backstage Software Templates / Port Actions / eigene CLI), damit ein neuer Dienst in Minuten von der Idee bis zur Produktion entsteht. Architektur des Service-Katalogs: Entwurf des Entitätsmodells für die reale Organisationsstruktur, Automatisierung der Verfolgung von Zuständigkeiten, Automatisierung der Verfolgung von Abhängigkeiten, Reifegradbewertung. Beherrschung der DORA-Metriken: Umsetzung automatisierter Erfassung (von rohen Git- + Deployment-Daten bis zum Dashboard), monatliche Review-Meetings zu Kennzahlen, Verantwortung für Zielsetzung + Verbesserungsinitiativen. Anwendung des SPACE-Frameworks: Entwicklerumfragen entwerfen + durchführen, Synthese qualitativen Feedbacks, Priorisierung von Maßnahmen. Interviewfähigkeiten mit Entwicklern: echte Probleme von oberflächlichen Beschwerden trennen (5-Whys-Methodik), übergreifende Themen erkennen. Strategie zur Einführung in mehreren Teams: „Plattform als Produkt“ — Produkteinführungen für neue Plattformfunktionen gestalten (private Beta → interner Launch → Verfolgung der Nutzungskennzahlen). Teamübergreifende Koordination: Arbeit mit 10-20 Produktteams, die die Plattform nutzen — Feedback + Feature-Wünsche + Breaking Changes + Deprecation-Zyklen steuern. Systementwurf für Plattformen: IDP-Architektur für eine Engineering-Organisation am Whiteboard entwerfen, Multi-Region-Überlegungen, Begrenzung des Blast Radius. Kostenzuordnung für die Plattform: Chargeback- / Showback-Dashboards pro Team, Verteidigung des Budgets des Plattformteams gegenüber dem ROI. Soft Skills: Verfassen von ADRs für Plattformentscheidungen, technisches Schreiben (Plattformdokumentation + Onboarding-Materialien), Kommunikation mit der Führungsebene (Berichte über den Wert der Plattform an CTO / VP Engineering), Planung der Produkt-Roadmap, Einstellung + Mentoring von Junior / Middle Platform Engineers. Englisch ab Senior+ PFLICHT — die Platform-Engineering-Community (KubeCon Platform Engineering Day / Backstage Working Groups / platformengineering.org) ist englischsprachig. Optionaler Bonus: Open-Source-Beiträge zu Backstage / Crossplane / ArgoCD / Tekton — steigern den Marktwert deutlich (der Markt ist klein + Einstellungen laufen über die Community).