Platform
Engineering:
IDP aufbauen.
Wie eine Internal Developer Platform Entwicklerteams entlastet, woraus sie besteht und wie Sie sie in fünf Schritten aufbauen. Mit einem eigenen Abschnitt dazu, was davon in der Fabrik trägt, wo IT und OT an derselben Software arbeiten.
AI
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.
Platform Engineering ist der Aufbau interner Entwicklerplattformen (Internal Developer Platform, IDP). Über sie bekommen Entwicklerteams per Self-Service Infrastruktur, standardisierte Pipelines und Observability, statt jedes Mal eine eigene Toolchain zu bauen. Das Ziel ist, die kognitive Belastung der Teams zu senken. Das interne Entwicklerportal ist dabei die Oberfläche, die IDP der Unterbau; bekannte Portale sind Backstage, Port und Cortex.
Stand: 17. September 2026 · Backstage 1.55 · CNCF Platform Engineering Maturity Model · DORA-Report 2025
Das Problem dahinter kennen wir aus vielen Projekten. Nach zwei, drei Jahren DevOps pflegt jedes Team seine eigene Pipeline, seinen eigenen Helm Chart und seine eigene Ecke im Monitoring. Wer ein neues Team einarbeitet, zeigt ihm nicht einen Weg, sondern sieben, und jeder davon hängt an einer anderen Person.
Platform Engineering zieht daraus eine einfache Konsequenz: aus „You build it, you run it“ wird „You build it, we make it easy to run it“.
Für Industrial DevOps ist das doppelt interessant. Im Werk liefert die IT mehrmals pro Woche aus, während die Automatisierung ihre SPS-Stände noch per Projektarchiv verteilt. Eine Plattform ist der Ort, an dem beide denselben Weg nutzen. Wie das aussieht, zeigt Abschnitt 08.
Quellen: DORA, Capability Platform Engineering. Gartner hatte 2022 vorhergesagt, dass bis 2026 rund 80 % der großen Software-Engineering-Organisationen Platform Teams aufbauen (2022: 45 %). Teamgröße und Verhältnis sind Erfahrungswerte aus unseren Projekten.
Ist Platform Engineering bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Ohne Plattform.
Mit Plattform.
„You build it, you run it“ funktioniert gut, solange ein Team überschaubar viel betreibt. Mit jedem neuen Werkzeug wächst aber, was ein Entwickler im Kopf haben muss: Kubernetes, Pipeline-Syntax, Monitoring, Security-Scanner, Infrastructure as Code.
Der Verlust fällt selten als Ausfall auf. Er steckt im Nachmittag, an dem ein Entwickler herausfindet, warum die Pipeline des Nachbarteams anders signiert als die eigene. Und in dem Wissen, das mit dem Kollegen geht, der als Einziger verstand, wie die Staging-Umgebung entsteht.
AI- Jedes Team baut seine Pipelines selbst
- Deployment-Wege unterscheiden sich von Team zu Team
- Entwickler verbringen Stunden mit YAML statt mit Fachlogik
- Umgebungen kommen per Ticket, nach Tagen
- Wissen steckt in einzelnen Köpfen
- Standardisierte Pipelines als Self-Service
- Golden Paths für die häufigsten Aufgaben
- Entwickler arbeiten an der Fachlogik
- Umgebungen in Minuten statt Tagen
- Wissen steckt in der Plattform, versioniert in Git
Was ist Platform
Engineering?
Platform Engineering ist die Disziplin, Internal Developer Platforms (IDP) zu entwerfen, zu bauen und zu betreiben. Eine IDP ist eine Schicht aus Tools, APIs, Vorlagen und Dokumentation, über die Entwicklerteams alles Nötige selbst abrufen, ohne Ticket und ohne Wartezeit auf ein zentrales Ops-Team.
Der Unterschied zum klassischen Betriebsteam liegt in der Haltung. Das Platform Team behandelt die Plattform als internes Produkt: mit Roadmap, mit den Entwicklerteams als Kunden und mit Erfolg, der sich an Nutzung und Zufriedenheit misst.
Die Begriffe Platform Team und Thinnest Viable Platform stammen aus dem Buch Team Topologies von Matthew Skelton und Manuel Pais. Wie sich Teams danach schneiden lassen, begleiten wir im DevOps Coaching. Die Kurzdefinition steht im Glossar unter Platform Engineering.
Es Teams so leicht wie möglich machen, das Richtige zu tun, mit Self-Service, Automatisierung und vernünftigen Voreinstellungen.
Was unterscheidet Platform Engineering
von DevOps und SRE?
DevOps liefert die Kultur, Platform Engineering die Werkzeuge und Site Reliability Engineering (SRE) die Zuverlässigkeit im Betrieb. Die drei ersetzen einander nicht, sie beantworten verschiedene Fragen.
Eine Warnung aus der Forschung gehört dazu. Der DORA-Report 2024 fand, dass Plattformen die Produktivität heben, Durchsatz und Stabilität der Änderungen aber sinken können, wenn niemand die Plattform selbst gut betreibt. Eine Plattform ist Software, und schlechte Software bremst.
Im Mittelstand übernimmt oft ein einziges Team alle drei Rollen: Es treibt die DevOps-Kultur, baut die Plattform und hält die Produktion stabil. Die Trennung ist eine gedankliche, keine organisatorische. Wichtig ist nur, dass jemand bewusst an der Plattform arbeitet und nicht bloß an Toil, der manuellen Routinearbeit, die sich endlos wiederholt.
Internes Entwicklerportal
oder interne
Entwicklerplattform?
Das interne Entwicklerportal ist die Oberfläche, die interne Entwicklerplattform (Internal Developer Platform, IDP) der Unterbau, und Platform Engineering die Disziplin, die beides als Produkt betreibt. Wer nur das Portal einführt, bekommt einen Katalog ohne Knöpfe. Wer nur die Plattform baut, hat Self-Service-APIs, die niemand findet.
Die Frage kommt meist in derselben Lage auf. Ein Team hat ein Developer Portal evaluiert, die Demo hat überzeugt, und dann zeigt sich, dass hinter den Templates noch nichts steht, was sie ausführen könnte. Die Reihenfolge lautet deshalb fast immer: erst der Golden Path, der wirklich automatisiert, dann das Portal darüber.
- /01
Internes Entwicklerportal
Die Oberfläche.
Service-Katalog, Software-Templates, Dokumentation, Ownership und Scorecards an einer Stelle. Das Portal zeigt, was existiert, wem es gehört und welcher Weg empfohlen ist. Ausgeführt wird die Aktion eine Schicht tiefer.
Typisch: Backstage, Port, Cortex, OpsLevel
- /02
Interne Entwicklerplattform (IDP)
Der Unterbau.
Englisch Internal Developer Platform. Sie ist das, was tatsächlich passiert, wenn jemand im Portal auf „Service anlegen“ klickt: Provisioning, Pipelines, Policies, Observability. Die IDP funktioniert auch ohne Portal, dann über Repository-Templates und eine Kommandozeile.
Typisch: Crossplane, Terraform, Argo CD, Kyverno, OpenTelemetry
- /03
Platform Engineering
Die Disziplin.
Das Team, das beides als internes Produkt betreibt, mit Roadmap, internen Kunden, gemessener Adoption und Betrieb. Fehlt diese Rolle, veraltet die Plattform binnen eines Jahres, weil niemand die Templates nachzieht.
Typisch: Produktverantwortung, Roadmap, Adoption-Metriken, SLAs
Wofür steht IDP im
Platform Engineering?
Im Platform Engineering steht IDP für Internal Developer Platform, also die interne Entwicklerplattform. Die zweite Bedeutung stammt aus der IT-Sicherheit. Dort meint IdP den Identity Provider, den Dienst, der Anmeldungen per SAML oder OIDC ausstellt. Beide begegnen Ihnen im selben Stack und haben nichts miteinander zu tun.
Die Verwechslung kostet echte Zeit. Wer im Architektur-Meeting „wir brauchen einen IDP“ sagt, meint je nach Sitznachbar eine Self-Service-Plattform oder Keycloak. Schreiben Sie die Abkürzung beim ersten Auftreten aus; das kostet vier Wörter und spart eine halbe Sitzung. Beide Begriffe sauber getrennt finden Sie unter Internal Developer Platform (IDP) im Glossar.
Ein Portal beantwortet die Frage „Welche Services gibt es, und wem gehören sie?“ Eine Plattform beantwortet „Wie bekomme ich in zehn Minuten einen neuen Service, der die Compliance-Regeln erfüllt?“ Welches Portal die richtige Basis ist, hängt weniger an der Feature-Liste als am Betriebsaufwand. Die Vor- und Nachteile von Backstage gegenüber Port und Cortex haben wir im Anwendungsfall für IT-Unternehmen nebeneinandergelegt.
Aus welchen Bausteinen
besteht eine IDP?
Eine Internal Developer Platform besteht aus fünf Bausteinen: Provisioning, Pipelines, Observability, Security Guardrails und dem Developer Portal. Kaum ein Unternehmen braucht alle fünf vom ersten Tag an. Fangen Sie dort an, wo die Teams am meisten Zeit verlieren. Zu jedem Baustein steht unten, wie er in der Fabrik aussieht.
- /01
Infrastructure Provisioning
Umgebungen und Cloud-Ressourcen per Self-Service.
Ein Team fordert eine Umgebung, Datenbank oder Message Queue an und hat sie nach Minuten, weil die Plattform sie aus deklarativen Modulen erzeugt. Crossplane bildet Cloud-Ressourcen als Kubernetes-Objekte ab und passt, wenn die Plattform ohnehin auf Kubernetes steht. Terraform deckt zusätzlich VMs, Netzwerk und Geräte außerhalb des Clusters ab.
Typische Tools: Terraform, OpenTofu, Crossplane, Pulumi
In der Fabrik: Testanlage, virtuelle SPS oder Edge-Gateway für ein Projekt bereitstellen
- /02
Deployment Pipelines
CI/CD als wiederverwendbare Vorlage.
Alle Teams nutzen dieselben Quality Gates, Security-Checks und Rollout-Strategien. Wer eine neue Pipeline braucht, bindet die Vorlage ein und schreibt sie nicht von vorn.
Typische Tools: Jenkins Shared Libraries, GitLab CI Templates, GitHub Actions, Argo CD
In der Fabrik: SPS-Projekt bauen, gegen die virtuelle Steuerung testen, im Wartungsfenster ausrollen
- /03
Observability
Monitoring, Logging und Tracing als Dienst.
Teams instrumentieren ihre Services mit wenigen Zeilen und bekommen Dashboards und Alerts, die schon eingerichtet sind. Einen eigenen Monitoring-Stack pro Team gibt es nicht mehr.
Typische Tools: Prometheus, Grafana, OpenTelemetry, Datadog
In der Fabrik: Maschinen- und Pipeline-Daten über OPC UA oder MQTT im selben Dashboard
- /04
Security Guardrails
Policy-as-Code statt Freigabe per E-Mail.
Schwachstellen-Scans und Compliance-Regeln laufen in jeder Pipeline mit. Ein Verstoß stoppt den Build, bevor er in Produktion kommt, und nicht erst im nächsten Audit.
Typische Tools: OPA/Gatekeeper, Kyverno, Trivy, Snyk
In der Fabrik: Prüfregeln aus IEC 62443, etwa welche Zone mit welcher sprechen darf
- /05
Developer Portal
Die Startseite der Plattform.
Service-Katalog, Dokumentation, API-Referenzen, Templates und Ownership an einer Stelle. Das Portal zeigt, was existiert und wem es gehört; die Arbeit erledigen die Bausteine darunter.
Typische Tools: Backstage, Port, Cortex, OpsLevel
In der Fabrik: Anlagenkatalog: welcher Softwarestand läuft auf welcher Linie, wer hat ihn freigegeben
Was ist ein
Golden Path?
Ein Golden Path ist der empfohlene, fertig gebaute Weg für eine häufige Aufgabe. Netflix nennt dasselbe Prinzip Paved Road. Teams dürfen abweichen, wenn sie gute Gründe haben. Der Weg ist aber so bequem, dass die meisten ihn freiwillig nehmen.
Guardrails sind die Regeln daneben: Policies, Security-Checks und Compliance-Vorgaben, die die Plattform automatisch prüft. Sie halten niemanden auf, der auf dem Weg bleibt. Sie greifen erst, wenn eine Änderung etwas Gefährliches tun würde, etwa ein Image ohne Signatur ausrollen.
Drei aus der IT, einer aus der Automatisierung. Der vierte zeigt, dass das Prinzip nicht an Kubernetes hängt.
- /01
Neuen Microservice anlegen
- 01Template im Developer Portal auswählen
- 02Repository entsteht mit Pipeline, Dockerfile und Helm Chart
- 03Erste Pipeline läuft, der Service steht in Staging
- 04Dashboard und Alerts sind schon eingerichtet
- /02
Datenbank bereitstellen
- 01Formular: Typ, Größe, Region
- 02Ein Terraform-Modul legt die Datenbank an
- 03Zugangsdaten landen im Secret-Manager
- 04Backup-Policy und Monitoring sind aktiv
- /03
Vorschau-Umgebung pro Pull Request
- 01Pull Request öffnen
- 02Die Plattform baut eine Vorschau-Umgebung
- 03Die URL steht als Kommentar im Pull Request
- 04Nach dem Merge wird die Umgebung wieder gelöscht
- /04
SPS-Änderung auf eine Linie bringen
- 01Änderung im Git-Branch des SPS-Projekts
- 02Pipeline übersetzt und testet gegen eine virtuelle Steuerung (z. B. PLCSIM Advanced)
- 03Schichtleitung gibt im Portal frei, Freigabe und Prüfbericht werden gespeichert
- 04Rollout im Wartungsfenster, der Softwarestand ist pro Anlage dokumentiert
Was bringt Platform
Engineering
in der Fabrik?
In der Industrie bringt Platform Engineering IT und OT auf einen gemeinsamen Weg: SPS-Code, Edge-Software und Cloud-Services laufen durch dieselbe Pipeline, mit derselben Freigabe und demselben Nachweis. Die Plattform ist dort meist schlanker als in der Cloud, und das ist richtig so.
Genau das ist der Kern von Industrial DevOps: Software für Maschinen und Anlagen so ausliefern, wie gute IT-Teams es längst tun, ohne die Regeln der Produktion zu brechen.
AIEin Beispiel aus dem Alltag: Eine Automatisierungsingenieurin ändert eine Schrittkette. Ohne Plattform überträgt sie das Projekt vom Laptop auf die Anlage und trägt den Stand hinterher in eine Excel-Liste ein, wenn die Schicht es zulässt. Mit Plattform schiebt sie die Änderung in einen Branch. Die Pipeline übersetzt das Projekt, testet es gegen eine virtuelle Steuerung, prüft die Regeln nach IEC 62443 und rollt im geplanten Wartungsfenster aus.
Fragt dann der Auditor, wer die Änderung an Linie 3 wann freigegeben hat, ist die Antwort ein Eintrag im Deployment-Protokoll mit Name, Zeitpunkt und Prüfbericht. Niemand muss dafür einen Aktenordner suchen.
Ehrlich gesagt ist die OT beim Self-Service noch nicht so weit wie die IT. Viele Engineering-Werkzeuge lassen sich nur eingeschränkt automatisieren, und nicht jede Steuerung hat eine brauchbare Simulation. Wie weit Golden Paths in der SPS-Entwicklung heute tragen, ordnet unser Artikel Platform Engineering in der Industrie im Detail ein. Den Hintergrund zur IT/OT-Konvergenz erklärt das Glossar.
- 01SPS-Projekte, HMI und Edge-Software in Git statt auf dem Netzlaufwerk
- 02Eine Pipeline, die gegen eine virtuelle Steuerung testet
- 03Eine Freigabe, die Name, Zeitpunkt und Prüfbericht speichert
- 04Einen Katalog: welcher Stand läuft auf welcher Anlage
- 05Security-Regeln nach IEC 62443 als automatische Prüfung
Abb. 5 · Die gemeinsame Pipeline als Kern einer Plattform zwischen IT und OT
Wie baue ich eine
Internal Developer Platform auf?
Eine Internal Developer Platform bauen Sie in fünf Schritten auf, klein beginnend und an echter Nachfrage entlang. Der teuerste Fehler ist der große Wurf: zwölf Monate an einer Plattform bauen, die kein Team bestellt hat, und dann zusehen, wie das erste Pilotteam sie nicht annimmt.
Wo Sie stehen, zeigt das Platform Engineering Maturity Model der CNCF. Es bewertet fünf Aspekte getrennt, denn kaum eine Organisation ist überall gleich weit.
Quelle: CNCF TAG App Delivery, Platform Engineering Maturity Model. In unseren Projekten erreichen mittelständische Unternehmen die Stufe Scalable bei den Schnittstellen typischerweise nach 12 bis 18 Monaten.
- /01
Engpässe erfassen
Fragen Sie Ihre Teams, wo sie Zeit verlieren, was sich wiederholt und worauf sie warten. Zählen Sie nach, wie lange ein neues Team bis zum ersten Deployment in Produktion braucht. Diese eine Zahl ist später Ihr wichtigster Vergleichswert.
- /02
Thinnest Viable Platform festlegen
Der Begriff stammt aus Team Topologies: die kleinste Plattform, die Teams wirklich entlastet. Suchen Sie den einen Engpass, der die meisten Teams trifft, und lösen Sie ihn zuerst. In IT-Organisationen ist das oft die Bereitstellung von Umgebungen, in der Fertigung meist die Versionierung der SPS-Projekte.
- /03
Platform Team benennen
Zwei bis vier Personen, die ausschließlich an der Plattform arbeiten und die Entwicklerteams als Kunden behandeln, mit Roadmap, Feedback-Runden und Zusagen zur Verfügbarkeit. Wer das Team nebenbei Tickets abarbeiten lässt, bekommt keine Plattform.
- /04
Ersten Golden Path automatisieren
Bauen Sie den einfachsten Weg, einen neuen Service anzulegen und auszurollen, und zwar vollständig automatisiert. Der Weg muss so bequem sein, dass Teams ihn freiwillig nehmen. Das Portal kommt danach.
- /05
Messen und ausbauen
Verfolgen Sie Adoption, Time-to-First-Deploy und die Zufriedenheit der Teams. Ausgebaut wird, was die Teams nachfragen, nicht was im Architekturdiagramm gut aussieht.
Wer vor Schritt 1 wissen will, wo das eigene Team insgesamt steht, beginnt mit dem DevOps-Reifegrad-Check.
15 Minuten · ohne Anmeldung · Ergebnis sofort
Woran erkennen Sie,
dass die Plattform wirkt?
Eine Plattform wirkt, wenn Teams sie freiwillig nutzen und schneller in Produktion kommen. Messen Sie dafür die Adoption, die Zeit bis zum ersten Deployment eines neuen Teams, die vier DORA-Metriken und regelmäßig die Zufriedenheit der Entwickler, etwa nach dem SPACE-Framework.
Den ersten Ertrag sieht man selten in einem Dashboard. Ein Entwickler braucht eine Testumgebung, klickt sie sich selbst zusammen und hat sie nach acht Minuten. Vorher war das ein Ticket und drei Tage Warten. Nach so einem Vormittag fragen die Nachbarteams von allein, wann sie dazukommen.
Neu im DORA-Report 2025 ist der Zusammenhang mit KI. Bei hoher Plattformqualität wirkt sich der Einsatz von KI-Assistenten deutlich positiv auf die Leistung der Organisation aus, bei niedriger Qualität kaum. Die Plattform entscheidet also mit, ob Coding-Agenten Zeit sparen oder nur schneller Unordnung erzeugen. Details zu den Kennzahlen stehen in unserem Artikel DORA-Metriken messen.
Die Plattform liefert die Werkzeuge. Genutzt werden sie nur, wenn die Teams sich trauen, Fehler offen anzusprechen. Mehr dazu unter DevOps-Kultur mit psychologischer Sicherheit und Fehlerkultur.
Das Deployment-Rückgrat vieler Plattformen ist heute GitOps mit Argo CD, mit App-of-Apps, ApplicationSets und Multi-Cluster-Sync. Typische Fehlerbilder wie OutOfSync-Zustände oder falsch gesetzte Sync-Waves behandeln wir im Workshop ArgoCD & GitOps mit KI.
Was Kunden
wirklich fragen.
- Was ist Platform Engineering?
- Platform Engineering ist die Disziplin, interne Entwicklerplattformen (Internal Developer Platforms, IDP) zu entwerfen und als Produkt zu betreiben. Entwicklerteams bekommen darüber Self-Service-Zugang zu Infrastruktur, Deployments und Observability, statt jedes Mal eine eigene Toolchain zu bauen. Das senkt die kognitive Belastung der Teams.
- Wie baue ich eine Internal Developer Platform auf?
- Eine Internal Developer Platform entsteht schrittweise: Engpässe der Teams erfassen, die kleinste nützliche Plattform (Thinnest Viable Platform) festlegen, ein kleines dediziertes Platform Team benennen, den ersten Golden Path automatisieren und danach an Adoption und Durchlaufzeit messen. Wer mit dem Portal beginnt statt mit dem automatisierten Weg dahinter, baut eine Oberfläche ohne Funktion.
- Was ist der Unterschied zwischen einem internen Entwicklerportal und einer internen Entwicklerplattform?
- Das interne Entwicklerportal (Developer Portal) ist die Oberfläche mit Service-Katalog, Templates, Dokumentation und Ownership. Die interne Entwicklerplattform (Internal Developer Platform, IDP) ist der Unterbau, der beim Klick tatsächlich etwas tut: Provisioning, Pipelines, Policies, Observability. Platform Engineering ist die Disziplin, die beides als Produkt betreibt. Ein Portal ohne Plattform ist ein Katalog ohne Knöpfe, eine Plattform ohne Portal eine Sammlung von APIs, die niemand findet.
- Wofür steht IDP im Platform Engineering?
- Im Platform Engineering steht IDP für Internal Developer Platform, die interne Entwicklerplattform, die Provisioning, Pipelines, Policies und Observability als Self-Service bereitstellt. Die gleichlautende Abkürzung IdP bezeichnet in der IT-Sicherheit den Identity Provider, also den Dienst, der Anmeldungen per SAML oder OIDC ausstellt. Beide kommen im selben Stack vor, meinen aber verschiedene Dinge.
- Was ist der Unterschied zwischen Platform Engineering und DevOps?
- DevOps beschreibt Kultur und Praxis der Zusammenarbeit von Entwicklung und Betrieb. Platform Engineering setzt darauf auf und baut die wiederverwendbaren Dienste, mit denen Teams diese Praxis ohne eigenen Infrastruktur-Unterbau leben können. Es löst die Überlastung, die entsteht, wenn jedes Team Kubernetes, Pipelines, Monitoring und Security selbst betreiben muss.
- Was macht ein Platform Engineer?
- Ein Platform Engineer baut und betreibt die interne Plattform: Infrastruktur-Module, Pipeline-Templates, Policies und die Automatisierung hinter dem Portal. Anders als im klassischen Betrieb arbeitet er nicht Tickets ab, sondern entwickelt Self-Service-Wege, die andere Teams ohne ihn nutzen können. Seine Kunden sind die Entwicklerteams im eigenen Haus.
- Braucht jede Internal Developer Platform ein Developer Portal?
- Nein, und oft ist das Portal nicht der richtige erste Schritt. Solange zwei bis drei Teams an der Plattform hängen, reichen ein Repository mit Templates und eine gute README. Ein Portal lohnt sich, sobald niemand mehr überblickt, welche Services existieren, wem sie gehören und welcher Golden Path für welchen Fall gilt. In unseren Projekten ist das ab etwa 30 bis 50 Services der Fall.
- Backstage, Port oder Cortex: welches Developer Portal passt?
- Backstage ist Open Source (ursprünglich von Spotify, heute CNCF-Projekt) und passt zu Organisationen mit eigenem Plattform-Team und hohem Anpassungsbedarf; bis zum produktiven Portal vergehen erfahrungsgemäß 6 bis 12 Monate. Port ist SaaS, schneller eingerichtet und bietet laut Preisseite (Stand September 2026) einen kostenlosen Plan bis 15 Nutzer, danach ab 30 US-Dollar pro Nutzer und Monat. Cortex (SaaS) legt den Schwerpunkt auf Service-Scorecards und Ownership und passt zu SRE-geprägten Organisationen mit vielen Services.
- Wann braucht mein Unternehmen Platform Engineering?
- Typische Anzeichen sind mehr als fünf Entwicklerteams, wiederkehrende Infrastruktur-Anfragen, lange Wartezeiten auf Umgebungen und uneinheitliche Deployment-Wege. Ein guter Test ist die Frage, wie lange ein neues Team bis zum ersten Deployment in Produktion braucht. Sind es Wochen statt Tage, lohnt der Blick auf eine Plattform.
- Lohnt sich Platform Engineering ab welcher Team-Größe?
- Nach unserer Erfahrung ab etwa fünf Produktteams oder 30 Entwicklern. Darunter reicht meist eine schlanke Sammlung von CI/CD-Templates und Infrastructure-as-Code-Modulen. Ab 50 Entwicklern ist ein dediziertes Platform Team die Regel.
- Welche Reifegrade gibt es im Platform Engineering?
- Das Platform Engineering Maturity Model der CNCF unterscheidet vier Stufen: Provisional, Operational, Scalable und Optimizing. Bewertet werden fünf Aspekte getrennt: Investment, Adoption, Interfaces, Operations und Measurement. Eine Organisation kann deshalb bei den Schnittstellen schon Self-Service bieten und bei der Messung noch am Anfang stehen.
- Was ist ein Golden Path?
- Ein Golden Path ist der empfohlene, vorgefertigte Weg für eine häufige Aufgabe, etwa einen neuen Service anlegen oder eine Datenbank bereitstellen. Er ist nicht verpflichtend, aber so gut gebaut, dass Teams ihn freiwillig nehmen. Netflix nennt dasselbe Prinzip Paved Road.
- Welche Tools brauche ich für Platform Engineering?
- Ein Standard-Toolset gibt es nicht. Häufig sind Backstage, Port oder Cortex als Developer Portal, Crossplane oder Terraform für das Provisioning, Argo CD für GitOps-Deployments, OPA oder Kyverno für Policy-as-Code und Prometheus mit Grafana für Observability. Crossplane verwaltet Cloud-Ressourcen als Kubernetes-Objekte und passt zu Plattformen, die ohnehin auf Kubernetes stehen; Terraform ist die breitere Wahl, wenn auch VMs, Netzwerk und Edge-Geräte dazugehören.
- Wie messe ich Developer Experience (DevEx)?
- Bewährt sind SPACE (Satisfaction, Performance, Activity, Communication, Efficiency; entwickelt von GitHub und Microsoft Research) und DX Core 4 (Speed, Effectiveness, Quality, Impact), ergänzt um die vier DORA-Metriken. Konkret messen Sie Time-to-First-Deploy neuer Teams, Deployment-Frequenz, Durchlaufzeit von Pull Requests und den Toil-Anteil pro Sprint.
- Wie hoch ist die Toil-Reduktion durch eine IDP?
- Im Median unserer Projekte 2023 bis 2025 sank der Toil-Anteil zwölf Monate nach Einführung von 40 bis 55 Prozent auf 15 bis 25 Prozent. Die Einrichtung neuer Services dauerte statt zwei bis vier Wochen noch ein bis zwei Tage, das Onboarding neuer Entwickler statt zwei Wochen noch drei Tage.
- Wie groß muss ein Platform Team sein?
- Für den Start reichen zwei bis vier Personen, sofern sie dediziert an der Plattform arbeiten und nicht nebenbei das Ops-Backlog abarbeiten. Als Faustregel planen wir einen Platform Engineer pro 10 bis 15 Anwendungsentwickler. Ab etwa 50 Entwicklern kommt eine Person dazu, die die Plattform als Produkt verantwortet.
- Wie hängen Platform Engineering und GitOps mit Argo CD zusammen?
- Argo CD und Flux sind das übliche Deployment-Backend einer IDP. Entwickler lösen Deployments über das Portal aus, die Plattform erzeugt daraus ApplicationSets in Git, und Argo CD synchronisiert sie auf die Cluster. Die IDP verbirgt das YAML, GitOps liefert Audit-Trail und Rollback.
- Ist Platform Engineering auch für industrielle Umgebungen relevant?
- Ja, wenn IT- und OT-Teams an derselben Software arbeiten. In der Fabrik ist die Plattform meist schlanker als in der Cloud: SPS-Projekte in Git, eine Pipeline, die gegen eine virtuelle Steuerung testet, eine Freigabe mit Protokoll und ein Katalog, der zeigt, welcher Softwarestand auf welcher Anlage läuft. Die Security-Regeln nach IEC 62443 laufen dabei als automatische Prüfung in der Pipeline mit.
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, Argo CD und Kubernetes als laufender Service mit SLA. So beginnen Sie mit Platform Engineering, ohne sofort Stellen aufzubauen.
Wie geht es bei Ihnen mit Platform Engineering weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
Platform Engineering in der Industrie: SPS & OT
Wie weit Golden Paths und Self-Service in der OT heute tragen, mit Beispielen aus der SPS-Entwicklung.
Was ist Industrial DevOps? Der komplette Leitfaden
DevOps-Prinzipien für cyber-physische Systeme, von der IT/OT-Konvergenz bis zur ersten Pipeline.
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Reifegradmodelle und Value-Stream-Mapping für Ihre DevOps-Bewertung.
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