Platform Engineering & Internal Developer Platform für IT-Unternehmen
Internal Developer Platform (Backstage, Port, Cortex), GitOps mit ArgoCD/Flux, SRE-Praktiken und Developer Experience. DevOps-Skalierung vom Münchner Standort aus für IT-Unternehmen im gesamten DACH-Raum.
SEIT 2006 · 47+ PROJEKTE · IT · ECOMMERCE · FINANCE · PLATFORM ENGINEERING
Wie skaliert man DevOps mit Platform Engineering?
Platform Engineering skaliert DevOps, indem ein dediziertes Platform-Team eine Internal Developer Platform (IDP) bereitstellt: Golden Paths, Self-Service-APIs und standardisierte Templates. Entwickler erhalten Environments, Pipelines und Deployments auf Knopfdruck. Die kognitive Last sinkt, die Developer Experience steigt, und DevOps-Praktiken tragen über 10, 20 oder 50 Teams statt nur im Pilotteam. Als IDP-Basis kommen Backstage, Port oder Cortex infrage; welche davon passt, entscheidet die verfügbare Engineering-Capacity, nicht der Hype.
Welche Probleme bremsen die
DevOps-Transformation?
Diese Probleme begegnen uns bei unseren Kunden immer wieder — und wir wissen, wie man sie löst.
- /01
Tool-Wildwuchs
Tool-Wildwuchs.
Jedes Team nutzt andere Tools: Jenkins hier, GitHub Actions dort, ein bisschen CircleCI dazwischen. Fehlende Standardisierung führt zu Wartungsaufwand und inkonsistenten Pipelines. Was das kostet, merkt man meist zum ungünstigsten Zeitpunkt, nämlich wenn der Kollege kündigt, der als Einziger wusste, warum der Release-Job seit drei Jahren diesen einen Groovy-Block braucht.
- /02
Langsame Cloud-Migration
Langsame Cloud-Migration.
Der Umzug von On-Premise in die Cloud stockt. Legacy-Anwendungen sind schwer zu containerisieren, Netzwerk-Abhängigkeiten unklar, und das Team hat zu wenig Cloud-Native-Erfahrung.
- /03
Fehlende Internal Developer Platform
Fehlende Internal Developer.
Entwickler verbringen mehr Zeit mit Infrastruktur als mit Features. Es gibt keinen Self-Service für Environments, keine standardisierten Templates und keine zentrale Anlaufstelle für Developer Tooling.
- /04
DevOps-Skalierung über Teams
DevOps-Skalierung über Teams.
DevOps funktioniert im Pilotteam, aber die Skalierung auf 10, 20 oder 50 Teams scheitert. Best Practices werden nicht geteilt, Governance fehlt, und jedes Team erfindet das Rad neu.
Wie skaliert man DevOps & Platform Engineering über
Teams?
Ein strukturierter, praxiserprobter Ansatz — von der Analyse bis zum messbaren Ergebnis.
Tool-Konsolidierung & Standardisierung
Analyse der bestehenden Toolchain, Bewertung nach Kriterien wie Team-Fit, Skalierbarkeit und Wartbarkeit. Konsolidierung auf eine einheitliche Plattform mit Migrations-Support für alle Teams.
Cloud-Migration-Roadmap
Strukturierte Migration von On-Premise über Hybrid bis Cloud-Native. Application Assessment, Containerisierung, Kubernetes-Einführung und schrittweiser Umzug, ohne Risiko für den laufenden Betrieb.
Internal Developer Platform (IDP)
Aufbau einer internen Developer Platform mit Self-Service-Portal, standardisierten Templates, automatischer Environment-Provisionierung und integrierten Observability-Tools. Backstage oder vergleichbare Plattformen als Basis. Ob sich das gelohnt hat, sehen Sie an dem Tag, an dem ein neues Team seinen Service selbst anlegt und vor der Mittagspause deployt, ohne Ticket und ohne Rückfrage bei der Plattform-Mannschaft.
DevOps-Coaching & Skalierung
Train-the-Trainer-Ansatz, Community of Practice, zentrale Governance mit dezentraler Ausführung. Wir begleiten die Skalierung von DevOps-Praktiken über alle Teams hinweg, mit messbaren KPIs und regelmäßigen Reviews.
Welche Ergebnisse bringt eine
DevOps-Transformation?
Welche Tools nutzt eine moderne Internal Developer
Platform?
Die Tools und Technologien, die wir in diesem Kontext einsetzen — herstellerunabhängig und passend zur bestehenden Infrastruktur.
DevOps-Transformation in Ihrem Unternehmen starten?
Lassen Sie uns sprechen. In einem kostenlosen Erstgespräch klären wir, wie wir Ihre spezifischen Herausforderungen lösen können.
Backstage, Port, Cortex: welche IDP passt?
Internal Developer Platforms verbessern die Developer Experience: weniger kognitive Last, schnelleres Onboarding, Self-Service statt Ticket-Queue. Welches Tool das richtige ist, hängt von Engineering-Capacity und Reifegrad ab, nicht vom Hype. Wie sich Platform Engineering von DevOps abgrenzt, zeigt unser Vergleich DevOps vs. Platform Engineering.
Was sind die Vor- und Nachteile von Backstage für Platform Engineering und Developer Experience?
Backstage punktet mit Open Source, der größten Plugin-Auswahl aller Developer Portals und einem Software-Katalog, der Templates und TechDocs aus einem Guss liefert. Sein Nachteil ist derselbe Umstand aus anderer Richtung: Es ist ein Framework, kein Produkt. Wer es einsetzt, entwickelt, hostet und aktualisiert eine eigene Anwendung. Für die Developer Experience entscheidet deshalb nicht die Funktionsbreite, sondern ob ein Platform-Team den Katalog dauerhaft pflegt.
- /01Open Source unter der CNCF, keine Lizenzkosten pro Entwickler
- /02Größte Plugin-Auswahl: CI/CD-Status, Kubernetes, Kosten und Security-Findings in einer Oberfläche
- /03Software-Templates erzeugen Repository, Pipeline und Standardkonfiguration per Klick
- /04TechDocs hält Dokumentation als Markdown neben dem Code, Docs-as-Code statt Wiki-Friedhof
- /01Framework statt Produkt: eigene Anwendung in TypeScript/React, die gebaut, gehostet und aktualisiert wird
- /02Plugin-Pflege: Upgrades brechen Community-Plugins, eigene Plugins binden Engineering-Capacity
- /03Ein leerer oder veralteter Katalog schadet der Developer Experience mehr als gar kein Portal
- /04Realistischer Betrieb: etwa zwei Vollzeit-Engineers dauerhaft, unterhalb dieser Schwelle ist Port meist günstiger
Welche Backstage-Alternative passt zu welchem Team?
Wer eine Alternative zu Backstage sucht, sucht meist keinen Funktionsersatz, sondern weniger Betriebsaufwand: Port liefert dieselben Self-Service-Kataloge als SaaS, ohne dass jemand Plugins, Upgrades und Hosting pflegt; Cortex setzt den Schwerpunkt auf Service-Reife und Standards-Durchsetzung statt auf Katalog-Breite. Backstage bleibt die richtige Wahl, wenn Sie ein eigenes Platform-Team dauerhaft finanzieren und die Plattform tief in bestehende Systeme integrieren wollen. Die ehrliche Prüffrage vor der Toolwahl lautet deshalb nicht „Welches Tool kann mehr?", sondern: Wer pflegt das Ding in zwei Jahren?
By 2026, 80 % of large software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery.
ArgoCD vs. Flux:
welcher Reconciler passt?
GitOps macht Git zur einzigen Quelle der Wahrheit für Cluster-Topologie und Deployments. Ein Reconciler synchronisiert den Live-Zustand kontinuierlich gegen den Soll-Zustand. Drift erkennt und korrigiert er automatisch.
Für Platform Teams heißt das: weniger Ad-hoc-kubectl, mehr Audit-Trail. ArgoCD glänzt mit UI, App-of-Apps und ApplicationSets für Multi-Cluster. Flux ist API-zentrierter, leichter und elegant in CNCF-/OpenTelemetry-Stacks. Comquent baut beide produktionsreif.
- /01
App-of-Apps & ApplicationSets
Skalierbares Bootstrapping: ein Root-App synchronisiert die Platform-Plane, ApplicationSets generieren Hunderte Apps deklarativ, etwa eine Variante pro Tenant oder Cluster.
- /02
Progressive Delivery mit Argo Rollouts
Canary, Blue/Green und Header-basierte Routing-Strategien. Automatisierte Promotions auf Basis von Prometheus- und Datadog-Metriken, Rollback in Sekunden.
- /03
Secrets, Policy, Provenance
External Secrets Operator + Vault, Kyverno/OPA-Policies in der Sync-Stage, Sigstore/cosign für signierte Images. Audit-Spuren landen direkt im Pipeline-Log.
- /04
Multi-Tenancy & Skalierung
AppProjects mit RBAC pro Team, sharded Repo-Server, Hochverfügbarkeit für ArgoCD-Controller, getestet in Setups mit 50+ Teams und 1.000+ Workloads.
SLOs, Error Budgets,
Toil-Reduktion.
SRE übersetzt Verfügbarkeit in messbare Verträge zwischen Produkt und Platform. Ohne diese Verträge skaliert DevOps nicht, dann verhandelt jedes Release aufs Neue, was „stabil genug" bedeutet.
Indikator und Ziel
Service Level Indicators (z. B. Erfolgsrate, Latenz p99) liefern die Daten; Service Level Objectives definieren Ziele über Rolling-Windows (z. B. 99,9 % über 28 Tage). Comquent etabliert SLI/SLO-Reviews als Quartalsritual.
Lizenz zum Risiko
Differenz zwischen 100 % und SLO ist das Error Budget. Solange es ungebraucht ist, darf das Team experimentieren und ausrollen; bei Erschöpfung schaltet das Team auf Stabilisierung um, ohne Diskussion.
< 50 % Operations
Toil ist repetitive, manuelle, automatisierbare Operations-Arbeit. Google-Faustregel: SRE-Teams sollten unter 50 % Toil-Anteil bleiben. Wir messen Toil als Pflicht-KPI und automatisieren systematisch.
SRE vs. DevOps: wo liegt der Unterschied?
DevOps beschreibt die Kultur, Site Reliability Engineering die konkrete Engineering-Praxis, „class SRE implements DevOps". DevOps sagt: Entwicklung und Betrieb tragen gemeinsam Verantwortung. SRE beantwortet die Anschlussfrage, woran man das misst: SLIs als Indikatoren, SLOs als Ziele, Error Budgets als Entscheidungsregel bei der Frage „ausrollen oder stabilisieren?". Die beiden konkurrieren also nicht. Ein Platform-Team ohne SRE-Praxis hat DevOps als Haltung, aber keine Zahlen, mit denen sich ein Konflikt zwischen Tempo und Stabilität sachlich klären lässt.
Was Entscheider
wirklich fragen.
- Q.01
- Wie skaliert man DevOps unternehmensweit?
- DevOps-Skalierung beginnt mit einem erfolgreichen Pilotprojekt und breitet sich dann über Communities of Practice, standardisierte Toolchains und Internal Developer Platforms aus. Wichtig: Nicht jedes Team muss denselben Weg gehen. Golden Paths setzen den Standard und lassen trotzdem Raum für Sonderfälle.
- Q.02
- Was ist eine Internal Developer Platform?
- Eine Internal Developer Platform (IDP) ist eine Self-Service-Schicht, die Entwicklern Infrastruktur, CI/CD-Pipelines, Monitoring und Deployment auf Knopfdruck bereitstellt. Sie abstrahiert Komplexität und ermöglicht Teams, sich auf die Produktentwicklung zu konzentrieren statt auf Infrastruktur.
- Q.03
- Wie funktioniert eine Cloud-Migration mit DevOps?
- Eine Cloud-Migration mit DevOps folgt einem iterativen Ansatz: Workloads werden priorisiert, Infrastructure as Code definiert die Zielarchitektur, CI/CD-Pipelines automatisieren die Migration und Tests validieren jeden Schritt. Der Übergang von On-Premise über Hybrid zu Cloud erfolgt schrittweise und risikoarm.
- Q.04
- Was ist Platform Engineering?
- Platform Engineering ist die Disziplin, interne Entwicklerplattformen zu entwerfen und zu betreiben. Platform-Teams bauen Golden Paths, Self-Service-APIs und standardisierte Templates, die anderen Teams produktives Arbeiten ermöglichen. Gartner prognostiziert, dass 80% der Organisationen bis 2026 dedizierte Platform-Teams haben werden.
- Q.05
- Platform Engineering vs. DevOps: was ist der Unterschied?
- DevOps beschreibt Kultur und Prinzipien: gemeinsame Verantwortung von Entwicklung und Betrieb, Automatisierung, kurze Feedbackschleifen. Platform Engineering ist die organisatorische Antwort darauf in der Skalierung: Ein dediziertes Platform-Team baut die Internal Developer Platform, mit der alle anderen Teams DevOps-Praktiken anwenden können, ohne selbst Infrastruktur-Tiefenwissen aufzubauen. Kurz: DevOps ist das Ziel, Platform Engineering der skalierbare Weg dorthin.
- Q.06
- Was ist ein Golden Path?
- Ein Golden Path ist der vom Platform-Team kuratierte Weg für eine wiederkehrende Aufgabe, etwa einen neuen Microservice aufzusetzen: Template, CI/CD-Pipeline, Observability und Security-Defaults inklusive. Golden Paths sind Opt-in statt Zwang: Teams, die dem Standard folgen, sind in Minuten produktiv; begründete Abweichungen bleiben möglich. Sie sind das wichtigste Werkzeug, um Standardisierung und Team-Autonomie gleichzeitig zu erreichen, und damit die Basis guter Developer Experience.
- Q.07
- Wann lohnt sich eine Tool-Konsolidierung?
- Eine Tool-Konsolidierung lohnt sich, wenn Teams unterschiedliche CI/CD-Tools nutzen, Wartungskosten steigen, Wissen fragmentiert ist und keine einheitlichen Best Practices existieren. Typische Migrationspfade: Jenkins → GitLab CI oder Azure DevOps, mit automatisierter Pipeline-Migration.
- Q.08
- Was ist GitOps für Platform Teams, und wann ArgoCD statt Flux?
- GitOps macht Git zur einzigen Quelle der Wahrheit für die Cluster-Topologie: Manifests, Helm-Releases, Konfigurationen. Ein Reconciler (ArgoCD oder Flux) sorgt dafür, dass der Live-Zustand dem Soll-Zustand entspricht. Bei Drift synchronisiert er automatisch. ArgoCD bietet eine starke UI, App-of-Apps-Patterns und ApplicationSets für Multi-Cluster. Flux ist API-zentrierter, leichter, integriert sich elegant in Notification-Controller und ist GitLab-/SOPS-affin. Comquent unterstützt beide; die Wahl hängt vom Operations-Modell und der gewünschten Multi-Tenancy ab.
- Q.09
- Was sind SLOs, Error Budgets und Toil, die SRE-Grundbegriffe?
- Site Reliability Engineering (SRE) übersetzt Verfügbarkeit in messbare Verträge: SLIs sind Indikatoren (z. B. Erfolgsrate, Latenz), SLOs sind Ziele (z. B. 99,9 % über 28 Tage), Error Budgets quantifizieren das erlaubte Fehlerkontingent. Toil ist repetitive, automatisierbare Operations-Arbeit. Ziel ist, sie unter 50 % der SRE-Zeit zu halten. Comquent etabliert SLO-Reviews, Error-Budget-Policies und Runbook-Automation für Platform Teams, die DevOps in Skalierung führen.
- Q.10
- Was sind die Vor- und Nachteile von Backstage für Platform Engineering und Developer Experience?
- Vorteile von Backstage: Open Source (CNCF), der größte Plugin-Katalog aller Developer Portals, Software-Katalog, Software-Templates und TechDocs aus einem Guss, vollständig anpassbar und ohne Lizenzkosten. Nachteile: Backstage ist ein Framework, kein Produkt. Sie entwickeln, hosten und aktualisieren eine eigene Anwendung, Plugins brechen bei Upgrades, und ohne ein dauerhaft finanziertes Platform-Team veraltet der Katalog innerhalb weniger Monate. Für die Developer Experience zählt deshalb weniger die Funktionsbreite als die Pflege: Ein halb gefülltes Portal schadet mehr als gar keins. Faustregel: ab etwa zwei Vollzeit-Engineers für die Plattform lohnt sich Backstage; darunter ist eine SaaS-IDP wie Port meist die bessere Wahl.
- Q.11
- Backstage vs. Port vs. Cortex: welche Internal Developer Platform passt?
- Backstage (Spotify, OSS) ist der Industriestandard mit großer Plugin-Community, braucht aber Engineering-Aufwand für Aufbau und Pflege. Port ist eine SaaS-IDP mit niedriger Time-to-Value, fokussiert auf Self-Service und Software-Katalog ohne eigene Infrastruktur. Cortex ist stark im Service-Reliability-Scoring und Engineering-Standards-Tracking. Faustregel: Engineering-Capacity vorhanden → Backstage; schnelle Adoption ohne Plattform-Team → Port; Service-Reife messen → Cortex. Comquent evaluiert die Tools an Ihrem Use Case.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD, Platform Engineering und Industrial Automation
Vertiefen.
Weiterdenken.
Fünf Einstiege in Platform Engineering, CI/CD, Jenkins-Betrieb und Reifegrad-Bewertung.
CI/CD Implementierung
Jenkins, GitLab CI, Azure DevOps und ArgoCD, herstellerübergreifend beraten und umgesetzt.
DevOps Automation as a Service
Managed CI/CD für IT-Teams ohne eigenes Platform-Engineering: Jenkins, GitLab CI, Azure DevOps und ArgoCD im SLA.
Platform Engineering: Der nächste Schritt nach DevOps
Wie Internal Developer Platforms die Produktivität steigern und DevOps skalierbar machen.
DevOps-Reifegrad-Check
In 3 Minuten erfahren, wo Ihre DevOps-Transformation steht und was als Nächstes ansteht.
Jenkins Administration Workshop mit KI
Jenkins für Platform Teams professionell betreiben oder auf Nachfolger migrieren, KI-gestützt.