Platform Engineering ersetzt klassische IT: Self-Service DevOps als neuer Standard

Platform Engineering hat sich 2026 von einem Buzzword zu einer konkreten Organisationsform entwickelt, die klassische IT-Strukturen ablöst. Laut InfoQ Cloud and DevOps Trends Report, ETR Research und SquareOps ist der Trend klar: Platform Teams wandeln sich von "Builders" zu "Enablers". Statt einfach Infrastruktur bereitzustellen, standardisieren sie AI-Capabilities, Governance und Developer-Workflows – und reduzieren dabei Shadow-Platform-Initiativen.

Was ist Platform Engineering?

Platform Engineering schafft Self-Service-Infrastruktur für Entwickler: Statt Tickets an Ops zu schicken ("Bitte erstelle mir ein Kubernetes-Cluster"), greifen Entwickler auf eine Internal Developer Platform (IDP) zu, die standardisierte Services bereitstellt.

Beispiel: Ein Developer braucht eine neue Microservice-Umgebung. Statt:

1. Ticket an Ops
2. Warten auf Cluster-Provisioning
3. Warten auf Netzwerk-Config
4. Warten auf Monitoring-Setup
5. Deployment

Nutzt er die Platform:

1. IDP aufrufen
2. Template wählen ("Node.js Microservice with PostgreSQL")
3. Deploy Button
4. Fertig – alles automatisch bereitgestellt, inklusive Monitoring, Logging, CI/CD

Internal Developer Portals (IDPs)

IDPs sind die Benutzeroberfläche von Platform Engineering. Populäre Tools:

• Backstage (Spotify Open Source, CNCF Incubating): Service Catalog, Tech Docs, Plugin-Ökosystem
• Humanitec: Cloud-native Developer Platforms, Score-Integration
• Cortex: Service Catalog und Platform Management mit Scorecards
• Atmosly: Self-Service DevOps Platform (erwähnt in SquareOps-Report)

Der Shift: Von Provisioning zu Enabling

InfoQ beschreibt den Wandel: "Rather than simply provisioning infrastructure, they are standardizing AI capabilities, governance, and developer workflows while reducing shadow platform initiatives."

Was bedeutet das konkret?

Früher (klassische IT/Ops):

• Ops Team provisioniert Server/Cluster auf Anfrage
• Jedes Team baut eigene Deployment-Workflows
• Jedes Team löst dieselben Probleme (Secrets Management, Monitoring, Logging)
• "Shadow IT": Teams bauen eigene Tools, weil offizielle zu langsam sind

Jetzt (Platform Engineering):

• Platform Team baut Self-Service-Plattform mit standardisierten Templates
• Entwickler deployen selbst, mit Best Practices baked-in
• Governance, Security, Compliance sind automatisch enforced
• Reduktion von Shadow Platforms, weil offizielle Platform schnell genug ist

Die drei Schichten eines Platform

ETR Research und InfoQ beschreiben typischerweise drei Ebenen:

1. Infrastructure Layer (Kubernetes, Cloud APIs)

Platform Engineers bleiben "grounded with the engines, the infrastructure and Kubernetes and whatnot".

2. Platform Layer (Standardized Services)

• CI/CD Templates
• Database Provisioning
• Secrets Management
• Monitoring & Logging
• Security Scanning

3. Developer Interface (IDP)

Selbsterklärende UI/CLI, wo Entwickler Services konsumieren, ohne Infrastruktur zu verstehen.

Warum jetzt?

Drei treibende Faktoren:

1. AI-Workloads erhöhen Komplexität

InfoQ: "Hyperscalers are investing in products already. Some of those hyperscalers are really putting the AI infrastructure in their products."

AI-Workloads brauchen spezielle Infrastruktur (GPUs, High-Bandwidth Networking, spezielle Storage). Platform Teams standardisieren Zugang zu AI-Capabilities, statt dass jedes Team eigene GPU-Cluster baut.

2. Entwickler-Produktivität als Wettbewerbsvorteil

Unternehmen erkennen: Wenn Entwickler 30% ihrer Zeit mit Infrastruktur-Tasks verbringen, ist das verschwendetes Engineering-Talent. Platform Engineering verschiebt das auf höhere Abstraktionsebenen.

3. Compliance & Governance ohne Friction

Regulatorische Anforderungen (GDPR, SOC2, DORA) erfordern nachweisbare Controls. Platform Engineering baked diese ein: Jeder Deployment über die Platform ist compliant by default.

Die Team Topologies Connection

Platform Engineering ist stark beeinflusst von Team Topologies (Matthew Skelton, Manuel Pais):

• Stream-Aligned Teams (Feature Teams) bauen Produkte
• Platform Teams bauen die Platform als Produkt für interne Entwickler
• Enabling Teams helfen Stream-Aligned Teams, Platform zu adoptieren
• Complicated Subsystem Teams (z.B. ML Platform) für spezialisierte Domänen

InfoQ bestätigt: "Matthew Skelton at QCon London: Team Topologies, Infrastructure, Agency, and AI" ist eine Schlüssel-Referenz.

Von Cloud-Native zu AI-Native

InfoQ Cloud Native Computing Foundation Coverage zeigt den Shift: "Cloud Native Infrastructure Emerges as the Foundation for Trustworthy Agentic AI".

Platform Teams bauen jetzt nicht nur Kubernetes-Foundations, sondern "Agent-Ready Platforms", die:

• Model Registries verwalten
• Inference Endpoints bereitstellen
• Agents orchestrieren
• Governance für AI-Workloads enforcen

Die Tooling-Landschaft

Infrastructure as Code Layer:

• Terraform/OpenTofu
• Pulumi (Code-driven IaC)
• Crossplane (Kubernetes-native IaC)

Platform Orchestration:

• Backstage
• Humanitec
• Cortex

GitOps Layer:

• ArgoCD
• Flux

Policy as Code:

• Open Policy Agent (OPA)
• Kyverno

Observability:

• Prometheus + Grafana
• OpenTelemetry

NoOps als Endgame?

SquareOps diskutiert "NoOps" als Evolution: Fully automated IT operations mit minimaler menschlicher Intervention, erreicht durch:

• Serverless Computing (AWS Lambda, Azure Functions)
• AI-driven auto-healing Infrastructure
• Self-managed Kubernetes Clusters

Platform Engineering ist der Weg dorthin: Je besser die Platform, desto weniger Ops werden gebraucht.

Die Herausforderungen

1. Platform as Product Mindset

Platform Teams müssen ihre Platform wie ein Produkt behandeln: Mit Roadmap, User Feedback, Developer Experience Focus. Viele Ops-Teams denken noch in "Ticket-Bearbeitung".

2. Adoption statt Enforcement

Die Platform muss besser sein als Shadow IT, sonst nutzt sie niemand. Enforcement funktioniert nicht – Developer Experience ist entscheidend.

3. Balance: Standardization vs. Flexibility

Zu rigide Platform? Teams finden Workarounds. Zu flexibel? Kein echter Wert. Die Balance ist schwer.

Erfolgsmessungen

Platform Teams messen sich an:

• Time to First Deployment (für neue Entwickler)
• Lead Time for Changes (DORA Metric)
• Platform Adoption Rate (% der Teams, die Platform nutzen)
• Shadow Platform Incidents (sollten sinken)
• Developer Satisfaction Surveys

Fazit: Developer auf Higher Abstraction Layers

InfoQ fasst es zusammen: "Developer has to be on the higher abstraction layers, and platform engineer can still stay grounded with the engines, the infrastructure and Kubernetes and whatnot."

Das ist der Deal: Platform Engineers bauen und optimieren Foundations, Entwickler bauen Business Value. Niemand schreibt mehr YAML Manifests von Hand, niemand ticketed mehr für Cluster-Provisioning.

Platform Engineering ist 2026 kein Experiment mehr – es ist die neue Organisationsform für moderne IT.