Warum Platform Engineering unverzichtbar ist – und wo DevOps versagt hat

Sebastian Scheele, CEO und Co-Gründer von Kubermatic, erläutert, wie sich die Softwareentwicklung entwickelt hat, welche Herausforderungen letztendlich zu einem neuen Ansatz geführt haben und warum er Platform Engineering für unverzichtbar hält. [...]

Moderne Software-Teams verfügen über mehr Tools als je zuvor. Pipelines, Konfigurationen, Dashboards, Warnmeldungen – und dennoch fühlt sich die Bereitstellung von Software immer noch schwieriger an, als sie sein sollte. Entwickler jonglieren neben dem eigentlichen Schreiben von Code auch noch mit YAML-Dateien, CI/CD-Pipelines und Cloud-Konfigurationen. DevOps-Teams müssen schauen, wo es brennt und sich gleichzeitig um einen ständig wachsenden Stack kümmern. Manager wiederum haben den Eindruck, dass sich die Softwarebereitstellung verlangsamt hat. Platform Engineering wurde entwickelt, um all diese Herausforderungen zu bewältigen.

Vor nicht allzu langer Zeit wurde Software nach dem Wasserfallmodell entwickelt: einem starren, schrittweisen Prozess, bei dem alles in einer bestimmten Reihenfolge geplant und abgeschlossen werden musste: Anforderungen, Design, Entwicklung, Test und Bereitstellung. Dies funktionierte, solange es nur selten Änderungen gab, bot aber wenig Spielraum, um frühere Entscheidungen zu überdenken und anzupassen. Diese mangelnde Flexibilität führte letztendlich zu langen Entwicklungszyklen, die mit dem schnellen Tempo des Geschäftslebens nicht Schritt halten konnten.

Dann kam Agile, das 2001 mit dem Agile Manifesto eingeführt wurde. Diese Methode führte zu kürzeren Zyklen, ständigem Feedback und mehr Flexibilität. Sie half Teams zweifellos dabei, schneller voranzukommen und sich besser anzupassen. Agile konnte allerding die Kluft zwischen Softwareentwicklung (Dev) und IT-Betrieb (Ops) nicht vollständig schließen. Entwickler konzentrierten sich darauf, Funktionen schnell zu erstellen und bereitzustellen, während Betriebsteams Stabilität und Verfügbarkeit priorisierten. Diese Diskrepanz führte häufig zu Reibungsverlusten und verlangsamte den gesamten Entwicklungsprozess.

Als DevOps an Grenzen stieß

Daraufhin kam DevOps ins Spiel. Um die Jahre 2007 bis 2008 gewann die DevOps-Bewegung an Fahrt. Sie hatte zum Ziel, diese Silos aufzubrechen und mehr Automatisierung, Zusammenarbeit und gemeinsame Verantwortung zu schaffen. Und es funktionierte – zumindest eine Zeit lang. DevOps brachte unbestreitbare Verbesserungen in Bezug auf die Zusammenarbeit und die gemeinsame Verantwortung zwischen Entwicklungs- und Betriebsteams. Mit zunehmender Komplexität der Softwaresysteme stießen die DevOps-Praktiken jedoch an ihre Grenzen.

Plötzlich wurde von den Entwicklern erwartet, dass sie alles managen: Infrastruktur, Bereitstellung, Überwachung, Sicherheit, Orchestrierung, CI/CD und vieles mehr. Die Belastung für die Teams stieg und sie verbrachten mehr Zeit mit der Pipeline als mit dem eigentlichen Schreiben von Software. Die Idee „You build it, you run it“ war zwar gut gemeint – in der Praxis überlastete sie die Teams jedoch mit zu vielen Tools und Aufgaben. DevOps trug zwar dazu bei, Silos aufzubrechen, schuf aber letztlich neue Herausforderungen in Bezug auf die Komplexität.

Platform Engineering als Weiterentwicklung von DevOps

Platform Engineering entstand als Weiterentwicklung von DevOps. Ziel war es, Teams die Entwicklung von Software zu erleichtern, ohne dass sie Experten in jedem Bereich des Tech-Stacks werden müssen. Dieser Ansatz schafft einen geebneten Weg – mit wiederverwendbaren Tools, Services und Standards, die unnötige Komplexität aus der täglichen Entwicklung entfernen. Entwickler müssen nicht jedes Mal von vorne anfangen. Sie erhalten Self-Service-Zugriff auf das, was sie benötigen, innerhalb eines sicheren und geregelten Rahmens. So können sich Teams auf die Entwicklung von Software konzentrieren, anstatt Tools und Pipelines zu verwalten.

Ebenso wichtig ist, dass Platform Engineering DevOps skalierbar macht. Anstatt dass jedes Team das Rad neu erfindet, sorgt Platform Engineering für Konsistenz und Wiederverwendbarkeit im gesamten Unternehmen. Im Kern befreit dieser Ansatz Teams von unnötigen Infrastrukturentscheidungen und ermöglicht es ihnen, sich auf das zu konzentrieren, was sie am besten können: das Entwickeln.

Was kommt als Nächstes?

Nachdem nun klar ist, warum Platform Engineering notwendig ist, wäre das nächste Thema, wie Platform Engineering in der Praxis aussieht. Dies bedeutet, wie IDPs (Internal Developer Platforms) funktionieren und wie sie Teams dabei helfen, produktiv zu bleiben, ohne überfordert zu sein.