Platform Engineering ist die Disziplin, eine interne Entwicklerplattform zu entwerfen und zu betreiben: ein integriertes Self-Service-Angebot aus Tools, APIs, Vorlagen und Infrastruktur, mit dem Produktteams Software bauen, ausliefern und betreiben. Ein Plattformteam behandelt die Plattform als Produkt, senkt die kognitive Last und verankert Sicherheit, Compliance und Observability von Anfang an.
Was ist Platform Engineering?
Platform Engineering bezeichnet den Aufbau und Betrieb einer internen Plattform, mit der Produktteams ihre Software ausliefern und betreiben. Statt dass jedes Team eigene CI/CD-Pipelines, Kubernetes-Manifeste, Secret-Verwaltung, Monitoring und Datenbankbereitstellung zusammenbaut, stellt ein Plattformteam diese Fähigkeiten als Self-Service-Produkt bereit. Das Ergebnis heißt meist Internal Developer Platform (IDP) oder interne Entwicklerplattform.
Das Platforms White Paper der CNCF TAG App Delivery aus dem Jahr 2023 definiert eine Plattform für Cloud-native Computing sinngemäß als „integrierte Sammlung von Fähigkeiten, die nach den Bedürfnissen der Plattformnutzer definiert und präsentiert werden“. Entscheidend sind die Begriffe integriert und Nutzer: Eine Plattform ist kein Sammelsurium von Tools, und ihre Nutzer sind die Entwicklerinnen und Entwickler im eigenen Unternehmen.
Warum Platform Engineering entstanden ist
DevOps hat Betriebsverantwortung in die Produktteams verlagert. Das stärkt Ownership, erhöht aber die kognitive Last erheblich. Ein Team, das Terraform-Module, Helm-Charts, IAM-Policies, Network Policies, OpenTelemetry-Konfiguration und fünf verschiedene Dashboards beherrschen muss, verbringt viel Zeit mit undifferenzierter Infrastrukturarbeit. Platform Engineering behält das Prinzip „You build it, you run it“ bei, bietet den Teams aber einen befestigten Weg, damit sie sich auf die Fachlogik konzentrieren können. Zugleich entsteht ein zentraler Ort, an dem sich Sicherheitsvorgaben durchsetzen und Toil abbauen lässt.
Merkmale einer guten Plattform
Das CNCF White Paper nennt sieben Eigenschaften erfolgreicher Plattformen:
- Plattform als Produkt: Das Plattformteam betreibt Nutzerforschung, pflegt eine Roadmap und misst die Nutzung.
- User Experience: konsistente Schnittstellen wie Portal, CLI und API.
- Dokumentation und Onboarding: Nutzer starten, ohne das Plattformteam fragen zu müssen.
- Self-Service: Fähigkeiten werden bei Bedarf bereitgestellt, nicht per Ticket.
- Geringere kognitive Last: Nutzer müssen nicht wissen, wie Fähigkeiten implementiert sind.
- Optional und kombinierbar: Teams können Teile nutzen und dennoch Sonderanforderungen umsetzen.
- Secure by Default: Compliance- und Sicherheitskontrollen sind im Golden Path eingebaut.
Typische Fähigkeiten einer internen Entwicklerplattform
| Fähigkeit | Beispiele |
|---|---|
| Golden-Path-Vorlagen | Service-Gerüste mit vorkonfiguriertem Build, Deployment und Telemetrie |
| Build- und Delivery-Automatisierung | CI-Pipelines, Progressive Delivery, Deployment-Verifikation |
| Infrastrukturdienste | Compute, Kubernetes-Namespaces, Netzwerk per Infrastructure as Code |
| Daten und Messaging | Datenbanken, Caches, Queues auf Anfrage |
| Identitäten und Secrets | Service-Identitäten, Secret Stores, Zertifikatsrotation |
| Observability | Standard-Instrumentierung, Collector, Dashboards und Alerts pro Service |
| Portal und Katalog | Service-Ownership, Dokumentation, Scorecards, etwa mit Backstage |
Observability als Plattformfähigkeit
Bei der Observability zahlt sich eine Plattform besonders schnell aus. Ein Golden Path kann jeden neuen Service mit OpenTelemetry-SDKs ausstatten, mit einheitlichen Resource-Attributen wie service.name und deployment.environment sowie einem vorkonfigurierten OpenTelemetry Collector, der Daten filtert und weiterleitet. Teams erhalten so vom ersten Tag an Traces, Metriken, Logs und ein Standard-SLO-Dashboard, während das Plattformteam Kosten und Datenqualität zentral steuert. Weil OpenTelemetry herstellerneutral ist, lässt sich das Backend wechseln, ohne jeden Service anzufassen.
Erfolg der Plattform messen
Plattformteams brauchen Belege dafür, dass die Plattform hilft. Nützliche Signale sind die Nutzung der Golden Paths, die Zeit bis zum ersten Deployment eines neuen Services, Zufriedenheitsumfragen unter Entwicklern und Delivery-Ergebnisse wie die DORA-Metriken. Zuverlässigkeitskennzahlen, gemeinsam mit SRE-Praktiken verantwortet, zeigen, ob Teams auf dem befestigten Weg stabilere Services betreiben.
Typische Fehler
- Eine Plattform bauen, nach der niemand gefragt hat, ohne mit ihren Nutzern zu sprechen.
- Die Plattform verordnen, statt sie zur einfachsten Option zu machen.
- Rohe Infrastruktur über ein Portal durchreichen und das Abstraktion nennen.
- Die Plattform als einmaliges Projekt behandeln statt als Produkt mit dauerhafter Verantwortung.
- Observability jedem Team selbst überlassen, was zu uneinheitlichen Namen und Lücken führt.
Wie Plattformteams organisiert sind
Das Buch Team Topologies beschreibt das Plattformteam als einen von vier grundlegenden Teamtypen, neben Stream-aligned-, Enabling- und Complicated-Subsystem-Teams. Seine Aufgabe ist es, produktnahen Stream-aligned-Teams autonomes Ausliefern zu ermöglichen, indem es interne Dienste anbietet, die sich mit minimaler Abstimmung nutzen lassen. Ein hilfreicher Leitgedanke aus demselben Buch ist die „Thinnest Viable Platform“: Beginnen Sie mit dem kleinsten Satz an Fähigkeiten, der echte Reibung beseitigt. Das können anfangs wenig mehr als dokumentierte Konventionen und einige Vorlagen sein. Ausgebaut wird anhand des Feedbacks der Nutzer. Plattformteams vereinen typischerweise Kompetenzen aus Infrastruktur, Entwickler-Tooling, Sicherheit und Observability und arbeiten bei Zuverlässigkeitsstandards eng mit SRE-Fachleuten zusammen.
Wie Obseria unterstützt
Obseria fügt sich als Observability-Fähigkeit in eine Plattform ein: Mit vorhandenen OpenTelemetry-SDKs instrumentierte Services senden Daten per OTLP, der Obseria Agent deckt Hosts und Kubernetes mit einer Installation pro Host ab, und Obseria Pipeline filtert, reichert an und maskiert Daten bereits beim Ingest. Der Service-Katalog und TopoGraph zeigen jedem Team Ownership und Abhängigkeiten. Über Automatisierungs-Workflows als Code, API, CLI und MCP-Server können Plattformteams Observability zusammen mit dem restlichen Golden Path bereitstellen.
