Platform
Engineering:
Nach DevOps.
Internal Developer Platforms, Self-Service-Infrastruktur und Golden Paths — wie Platform Engineering die kognitive Last für Entwicklerteams reduziert und DevOps auf die nächste Stufe hebt.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
DevOps hat Silos
aufgebrochen.
Platform baut Brücken.
Mit wachsender Anzahl an Teams, Services und Tools entsteht ein neues Problem: kognitive Überlastung. Jedes Team kämpft mit Kubernetes, CI/CD, Monitoring, Security, IaC — oft ohne tiefes Expertenwissen.
Platform Engineering entwickelt DevOps weiter: von „You Build It, You Run It" zu „You Build It, We Make It Easy to Run It".
Ohne Plattform.
Mit Plattform.
- —Jedes Team baut eigene CI/CD-Pipelines
- —Inkonsistente Deployment-Prozesse
- —30 % der Entwicklerzeit für Infrastruktur
- —Lange Wartezeiten auf Environments
- —Wissen verteilt in einzelnen Köpfen
- —Standardisierte Pipelines als Self-Service
- —Golden Paths für gängige Workflows
- —Entwickler fokussieren auf Fachlogik
- —Environments in Minuten statt Tagen
- —Wissen kodifiziert in der Plattform
Plattform als
internes Produkt.
Platform Engineering ist die Disziplin, Internal Developer Platforms (IDP) zu entwerfen, zu bauen und zu betreiben. Eine IDP ist eine Schicht aus Tools, APIs, Services und Dokumentation, die Entwicklerteams Self-Service-Zugang zu allem gibt, was sie brauchen.
Der entscheidende Unterschied zu einem klassischen Ops-Team: Das Platform Team betrachtet die Plattform als internes Produkt — mit Roadmap, Feedback von „Kunden" (Teams) und Erfolgsmessung an Adoption und Zufriedenheit.
Macht es für Teams so einfach wie möglich, das Richtige zu tun — durch Self-Service, Automatisierung und sinnvolle Defaults.
Kein einzelnes Tool.
Eine Komposition.
Jede Schicht adressiert einen bestimmten Aspekt der Developer Experience. Nicht jedes Unternehmen braucht alle Bausteine von Anfang an — starten Sie dort, wo der größte Schmerzpunkt liegt.
- /01
Infrastructure Provisioning
Self-Service für Umgebungen und Cloud-Ressourcen.
Entwickler fordern an, die Plattform liefert — innerhalb von Minuten statt Tagen. Umgebungen, Datenbanken, Message Queues und Cloud-Ressourcen als deklarative Assets.
Typische Tools: Terraform, Crossplane, Pulumi, AWS CDK
- /02
Deployment Pipelines
Standardisierte CI/CD als wiederverwendbare Templates.
Jedes Team nutzt die gleichen Quality Gates, Security-Checks und Deployment-Strategien — ohne sie selbst bauen zu müssen.
Typische Tools: Jenkins Shared Libraries, GitLab CI Templates, GitHub Actions, ArgoCD
- /03
Observability
Zentrales Monitoring, Logging und Tracing als Service.
Teams instrumentieren ihre Services mit wenigen Zeilen Code und erhalten sofort Dashboards und Alerts. Kein eigener Stack pro Team.
Typische Tools: Prometheus, Grafana, OpenTelemetry, Datadog
- /04
Security Guardrails
Policy-as-Code. Sicherheit als Default.
Automatisierte Vulnerability-Scans und Compliance-Checks — eingebettet in die Plattform. Sicherheit wird zum Standard, nicht zum Nachtrag.
Typische Tools: OPA/Gatekeeper, Trivy, Snyk, Kyverno
- /05
Developer Portal
Die Startseite Ihrer Plattform.
Zentrales Portal als Einstiegspunkt: Service-Katalog, Dokumentation, API-Referenzen, Templates und Team-Ownership.
Typische Tools: Backstage (Spotify), Port, Cortex, OpsLevel
Keine Konkurrenz.
Drei Rollen im Ensemble.
DevOps liefert die kulturelle Grundlage, Platform Engineering baut die Werkzeuge und SRE sorgt für Zuverlässigkeit im Betrieb.
In vielen Organisationen übernimmt ein Team mehrere Rollen. Ein kleines Unternehmen hat vielleicht ein Team, das DevOps-Kultur vorantreibt, die Plattform baut und die Zuverlässigkeit sicherstellt. Die Trennung ist konzeptionell — nicht organisatorisch.
Leitplanken.
Keine Vorschriften.
Ein Golden Path (auch „Paved Road") ist der empfohlene, vorgefertigte Weg für eine gängige Aufgabe. Er ist nicht der einzige Weg — Teams können davon abweichen, wenn sie gute Gründe haben. Aber der Golden Path ist so gut, dass die meisten Teams ihn freiwillig nutzen.
Guardrails sind die Leitplanken: Policies, Security-Checks und Compliance-Regeln, die automatisch durchgesetzt werden. Sie verhindern gefährliche Abweichungen — wie Leitplanken auf der Autobahn: sie schränken die Fahrt nicht ein, aber schützen vor Abstürzen.
Drei typische Workflows, die jede ausgereifte IDP anbietet.
- /01
Neuen Microservice erstellen
- 01Template im Developer Portal auswählen
- 02Repository wird automatisch erstellt (mit CI/CD, Dockerfile, Helm Chart)
- 03Erste Pipeline läuft, Service ist in Staging deployed
- 04Monitoring-Dashboard und Alerts sind vorkonfiguriert
- /02
Datenbank bereitstellen
- 01Self-Service-Formular: Typ, Größe, Region auswählen
- 02Terraform-Modul provisioniert die Datenbank
- 03Credentials werden automatisch im Secret-Manager hinterlegt
- 04Backup-Policy und Monitoring sind aktiv
- /03
Neues Environment für Feature-Branch
- 01Pull Request öffnen
- 02Preview-Environment wird automatisch erstellt
- 03URL wird als PR-Kommentar gepostet
- 04Environment wird nach Merge automatisch gelöscht
IT/OT zusammenbringen.
Durch Plattform.
In industriellen Umgebungen gewinnt Platform Engineering eine besondere Bedeutung. Die Herausforderung der IT/OT-Konvergenz — das Zusammenbringen von klassischer IT-Infrastruktur mit Operational Technology (SPS, SCADA, Edge-Gateways) — ist ein perfekter Anwendungsfall für eine Internal Developer Platform.
Ein Automatisierungsingenieur muss SPS-Code nicht manuell auf eine Anlage spielen, sondern nutzt einen Self-Service-Workflow der Plattform. Die Pipeline prüft automatisch gegen IEC-62443-Policies, führt Simulationstests durch und deployed in einem geplanten Wartungsfenster.
- —Self-Service-Provisioning für Edge-Gateways und Testumgebungen
- —Versionierte Deployment-Pipelines für SPS/PLC-Code (z. B. TIA-Portal)
- —Automatisierte Compliance-Checks gegen IEC 62443 und branchenspezifische Standards
- —Zentrales Monitoring für IT- und OT-Systeme in einem Dashboard
- —Golden Paths für die Inbetriebnahme neuer Produktionslinien
Kein Big Bang.
Iterativ ausbauen.
Klein starten, schnell Wert liefern und iterativ ausbauen. Fünf Schritte für den Einstieg.
- /01
Developer Experience messen
Befragen Sie Ihre Entwicklerteams: Wo verlieren sie Zeit? Welche Aufgaben wiederholen sich? Wo warten sie auf andere Teams? Diese Daten sind Ihr Kompass.
- /02
Thinnest Viable Platform definieren
Starten Sie nicht mit einer vollständigen IDP. Identifizieren Sie den einen Schmerzpunkt, der die meisten Teams betrifft — und lösen Sie diesen zuerst. Oft ist es Environment-Provisioning oder CI/CD-Templates.
- /03
Platform Team aufbauen
Ein dediziertes Team (2–4 Personen zum Start) übernimmt die Plattform als Produkt. Sie behandeln Entwicklerteams als Kunden — mit Roadmap, Feedback-Zyklen und SLAs.
- /04
Golden Paths implementieren
Bauen Sie den ersten Golden Path: den einfachsten Weg für Teams, einen neuen Service zu erstellen und zu deployen. Der Pfad muss so gut sein, dass Teams ihn freiwillig nutzen.
- /05
Messen, iterieren, skalieren
Tracken Sie Adoption-Rate, Time-to-Production und Developer Satisfaction. Bauen Sie die Plattform basierend auf echtem Feedback aus — nicht auf Annahmen.
Plattform als Produkt.
Nichts Geringeres.
Platform Engineering ist nicht das Ende von DevOps — es ist die logische Weiterentwicklung. Wenn DevOps die Mauern zwischen Dev und Ops eingerissen hat, baut Platform Engineering die Brücken, über die alle Teams effizient arbeiten können.
Der Schlüssel liegt im Mindset: Behandeln Sie Ihre interne Plattform als Produkt. Hören Sie Ihren Entwicklerteams zu, messen Sie die Developer Experience und iterieren Sie kontinuierlich. Starten Sie mit der Thinnest Viable Platform — dem kleinsten Baustein, der echten Wert liefert — und wachsen Sie von dort.
Besonders in industriellen Umgebungen, wo IT und OT zusammenwachsen, kann eine gut gebaute Plattform der Katalysator sein, der den Kulturwandel beschleunigt und die Komplexität beherrschbar macht.
Was Kunden
wirklich fragen.
- Q.01
- Was ist Platform Engineering?
- Platform Engineering ist die Disziplin, interne Entwicklerplattformen (Internal Developer Platforms, IDP) zu entwerfen und zu betreiben. Ziel ist es, Entwicklerteams Self-Service-Zugang zu Infrastruktur, Deployments und Observability zu geben — ohne dass jedes Team eigene Toolchains bauen muss.
- Q.02
- Was ist der Unterschied zwischen Platform Engineering und DevOps?
- DevOps ist die Kultur und Praxis der Zusammenarbeit zwischen Entwicklung und Betrieb. Platform Engineering ist eine Spezialisierung innerhalb von DevOps, die sich auf den Aufbau wiederverwendbarer Plattform-Dienste konzentriert. Platform Engineering löst das Problem der kognitiven Überlastung, das entsteht, wenn jedes Team alles selbst betreiben muss.
- Q.03
- Was ist eine Internal Developer Platform (IDP)?
- Eine IDP ist eine Schicht aus Tools, APIs und Self-Service-Workflows, die Entwicklerteams nutzen, um Infrastruktur bereitzustellen, Code zu deployen und Services zu überwachen. Beispiele sind Backstage (Spotify), Port, Humanitec oder eigene Lösungen auf Basis von Crossplane und ArgoCD.
- Q.04
- Wann braucht mein Unternehmen Platform Engineering?
- Typische Anzeichen: Mehr als 5 Entwicklerteams, wiederkehrende Infrastruktur-Anfragen, lange Wartezeiten auf Environments, inkonsistente Deployment-Prozesse oder hohe kognitive Last durch zu viele Tools. Wenn Ihre Entwickler mehr als 20–30 % ihrer Zeit mit Infrastruktur-Aufgaben verbringen, ist es Zeit für eine Plattform.
- Q.05
- Was ist ein Golden Path?
- Ein Golden Path ist der empfohlene, vorgefertigte Weg für eine gängige Aufgabe — zum Beispiel einen neuen Microservice erstellen oder eine Datenbank bereitstellen. Er ist nicht verpflichtend, aber so gut gestaltet, dass Teams ihn freiwillig nutzen.
- Q.06
- Welche Tools brauche ich für Platform Engineering?
- Es gibt kein Standard-Toolset. Häufig eingesetzt werden Backstage (Developer Portal), Crossplane oder Terraform (Infrastructure Provisioning), ArgoCD (GitOps-Deployments), OPA/Kyverno (Policy-as-Code) und Prometheus/Grafana (Observability). Wichtiger als die Tools ist das Konzept: Self-Service, Golden Paths und die Plattform als Produkt.
- Q.07
- Wie groß muss ein Platform Team sein?
- Starten Sie klein: 2–4 Personen reichen für den Anfang. Wichtig ist, dass das Team dediziert arbeitet und nicht nebenbei Tickets aus dem Ops-Backlog abarbeitet. Als Faustregel: Ein Platform Engineer pro 10–15 Anwendungsentwickler — aber das variiert je nach Komplexität.
- Q.08
- Ist Platform Engineering auch für industrielle Umgebungen relevant?
- Absolut. Gerade in der Industrie, wo IT- und OT-Teams zusammenarbeiten müssen, kann eine Plattform die Komplexität reduzieren: Self-Service-Pipelines für SPS-Code, automatisierte Compliance-Checks gegen IEC 62443 und zentrales Monitoring für IT- und OT-Systeme.
Sie wollen eine Plattform, ohne ein eigenes Platform-Team aufzubauen? Comquent betreibt CI/CD- und Plattform-Dienste als Managed DevOps Service (DevOps Outsourcing) — Jenkins, GitLab CI, Azure DevOps, ArgoCD und Kubernetes als laufender Service mit SLA. Pragmatischer Einstieg in Platform Engineering ohne FTE-Aufbau.
Verwandte Artikel
DevOps einführen: Schritt für Schritt
Der praxisorientierte Leitfaden zur DevOps-Einführung in Ihrem Unternehmen.
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Reifegradmodelle und Value-Stream-Mapping für Ihre DevOps-Bewertung.
Industrial DevOps: Der komplette Leitfaden
Was ist Industrial DevOps? CI/CD für cyber-physische Systeme und Industrie 4.0.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance