In dieser Episode von Tech Chat mit Navika Chadha, Cloud Engineer und Microsoft MVP, hatten wir ein ausführliches Gespräch über Platform Engineering: Was es ist, wie es sich von DevOps unterscheidet, warum Unternehmen es einführen sollten und welche Fähigkeiten benötigt werden. Die Diskussion schneidet durch den Buzz und die Click-Bait-Überschriften, um zu erklären, warum DevOps sehr lebendig ist und wie Platform Engineering es ergänzt.
Was ist Platform Engineering?#
Platform Engineering dreht sich um Befähigung. Ein Platform-Engineering-Team stellt eine Plattform als internes Produkt für die anderen Teams bereit, die Produkte entwickeln. Diese Plattform sollte alles enthalten, was die Produkt-Teams brauchen, um ihre Produkte schneller und effizienter zu entwickeln.
Das Platform-Team generiert Wert für die Produkt-Teams, und die Produkt-Teams generieren Wert für den Kunden. Der Grund, warum viele Unternehmen in diese Richtung gehen, ist einfach: Die kognitive Last auf den Produkt-Teams stieg. Sie mussten zu viele Tools, zu viel Technologie, zu viel Komplexität bewältigen. Es gab Redundanzen über Teams hinweg. Platform Engineering reduziert diese kognitive Last durch Standardisierung.
Platform Engineering ermöglicht es anderen Teams, DevOps zu machen. Es ist ein Enabler, kein Ersatz.
Warum sollten Unternehmen Platform Engineering einführen?#
Die Vorteile fliessen in zwei Richtungen. Für interne Teams (Softwareentwickler) steigert die Plattform die Effizienz durch Automatisierung und standardisiertes Tooling. Für Kunden und Nutzer resultiert es in konsistenterem, qualitativ hochwertigerem Output. Es ist eine Win-win-Situation.
Platform Engineering ist im Wesentlichen Standardisierung. Man gibt Teams einen “Golden Path,” einen empfohlenen Weg, Software zu bauen und bereitzustellen. Für etwa 80% der Anwendungsfälle sollte die Plattform die richtige Lösung sein. Aber man muss Teams immer die Freiheit lassen, auszubrechen und eigene Wege zu gehen, wenn es nötig ist.
Welche Fähigkeiten sollte eine Plattform haben?#
Jede Plattform sieht je nach Unternehmensbedürfnissen anders aus. Aber generisch erscheinen einige Fähigkeiten konsistent:
- Application Runtime: Wo Anwendungen laufen. Das kann On-Premise sein, Cloud, Docker, virtuelle Maschinen oder ein Kubernetes-Cluster.
- Automatisierung: Automatisierung wiederkehrender Aufgaben wie Zertifikatsrotation, Passwortwechsel und Schwachstellenmanagement (Container-Scanning, SCA, SBOM).
- Observability: Standard-Dashboards, Tracing und Monitoring, die bereits vorhanden sind, damit Teams das nicht jedes Mal von Grund auf aufbauen müssen.
- CI/CD-Pipelines: Vorgefertigte Pipelines mit sinnvollen Standardwerten, die Teams sofort für den Bau ihrer Produkte nutzen können.
Die Kernerkenntnis: Plattformen drehen sich hauptsächlich um wiederverwendbare, wiederholbare Aufgaben. Anstatt jedes Mal manuell von vorne anzufangen, standardisiert man, damit sich Teams auf das Wesentliche konzentrieren können: Features liefern.
DevOps vs. Platform Engineering: Ergänzung, kein Wettbewerb#
Es gibt viel Buzz, der behauptet, Platform Engineering werde DevOps ersetzen. Aber vieles davon ist Click-Bait. Hier ist die Realität:
Die DevOps-Bewegung begann damit, Entwicklung und Betrieb zusammenzubringen, und entwickelte sich dann in Richtung kontinuierlicher Wertlieferung, indem alle Menschen über den Value Stream hinweg einbezogen wurden. Das führte uns von Projekten zu Produkten. Aber das hat seinen Preis: Man muss Silos abbauen, was bedeutet, dass die kognitive Last auf den Teams steigt, weil sie alles selbst handhaben müssen.
Platform Engineering entstand als Antwort auf diese kognitive Last. Ein Platform-Engineering-Team nutzt DevOps-Praktiken, um die Plattform zu bauen. Produkt-Teams nutzen DevOps-Praktiken auf dieser Plattform, um ihre Produkte zu bauen. DevOps ist nicht tot. Es ist nach wie vor die Grundlage.
Platform Engineering und DevOps ergänzen sich. Platform Engineering ist das starke Fundament, das DevOps effizienter macht. Aber wenn man ein Startup mit einem Team ist, braucht man kein Platform Engineering. Man macht einfach DevOps. Der Platform-Engineering-Fall kommt ins Spiel, wenn man mehrere Teams mit Redundanzen hat und schneller werden will, während man die Kosten senkt.
Platform Engineering Tools#
Die Tool-Landschaft wächst rasant. Microsoft hat Tools in diesem Bereich veröffentlicht. OpenShift kann als Platform-Engineering-Tool betrachtet werden. Backstage ist ein sehr gutes Beispiel für ein Developer-Portal. Viele weitere Tools entstehen, und ich erwarte bald einen Gartner-Quadranten für Platform-Engineering-Tools.
Wichtig zu erkennen: Als Unternehmen oder Platform-Engineering-Team muss man schauen, was die Produkt-Teams wirklich brauchen. Ist es eine Standardplattform von der Stange oder eine massgeschneiderte Plattform, die auf anderen Plattformen aufbaut? Normalerweise bauen Unternehmen Plattformen auf Plattformen, indem sie Fähigkeiten stapeln. Der Schlüssel ist zu identifizieren, welche Fähigkeiten man braucht, welche man von bestehenden Plattformen übernehmen kann und welche man selbst bauen muss.
Sicherheit und Kostenüberlegungen#
Beim Bau einer eigenen Plattform gelten alle Sicherheitsmassnahmen. Es ist ein internes Produkt, also braucht man Penetrationstests, Sicherheitstests, License Scanning, SBOM-Analyse, alles. Eine gut gebaute eigene Plattform kann absolut sicher sein.
Die grössere Frage sind die Kosten. Der Bau einer Plattform erfordert mindestens ein Team von fünf bis sieben hochqualifizierten Personen mit 10+ Jahren Erfahrung in der Softwareentwicklung. Sie brauchen tiefes Wissen in Kubernetes, Pipelines, Sicherheit, Netzwerken, Backups und IT-Betrieb. Diese Investition ist erheblich. Aber für ein Unternehmen mit rund 1.000 Entwicklern und spezialisierten Entwicklungsbedürfnissen macht der Bau einer eigenen Plattform absolut wirtschaftlich Sinn. Für kleinere Organisationen kann eine Standardplattform kosteneffektiver sein.
Fähigkeiten für Platform Engineers#
Platform Engineering ist eine junge Disziplin, aber die Anforderungen an die Fähigkeiten werden klarer. Ein typisches Platform-Team braucht vielfältige Expertise:
- Frontend/UX: Portal-Interfaces bauen, oft auf Basis von Tools wie Backstage
- Kubernetes: Tiefes Wissen in Container-Orchestrierung ist essentiell
- Sicherheit: Verständnis von Schwachstellenmanagement, Netzwerkrichtlinien und Compliance
- Pipelines: Expertise in CI/CD-Automatisierung und Integration
- Netzwerke: Wissen über Service Meshes, Ingress und Netzwerktopologie
Das Standardprofil eines Platform Engineers ist jemand mit breitem Kubernetes-Wissen, Verständnis von Softwareentwicklungspraktiken, Kenntnis des Kunden (Software-Engineering-Teams) und Fähigkeiten in Pipeline-Automatisierung. Normalerweise deckt ein diverses Team verschiedene Spezialisierungen ab, anstatt dass eine Person alles abdeckt.
Kernaussagen#
- Platform Engineering befähigt Produkt-Teams, DevOps effizienter zu machen, indem es die kognitive Last reduziert
- DevOps ist nicht tot. Platform Engineering und DevOps ergänzen sich. Platform Engineering bietet die Grundlage, DevOps ist die Praxis.
- Plattformen sollten einen Golden Path für etwa 80% der Anwendungsfälle bieten und Teams Freiheit für die restlichen 20% lassen
- Die Build-vs.-Buy-Entscheidung hängt von Teamgrösse, Spezialisierungsbedarf und Kosten ab. Unternehmen mit 1.000+ Entwicklern können eigene Plattformen rechtfertigen.
- Platform Engineers brauchen ein vielfältiges Fähigkeitsprofil über Kubernetes, Sicherheit, Pipelines und Developer Experience
- Jede Plattform sollte die kognitive Last reduzieren und die Time to Productivity für neue Teammitglieder beschleunigen