DevOps vs. Platform Engineering

Was ist DevOps? Was ist Platform Engineering?

DevOps

Ganz einfach gesagt geht es bei DevOps um die grundlegende Automatisierung, die in der Softwareentwicklung erforderlich ist. Es geht darum, den Build-, Test- und Deployment-Prozess zu automatisieren. Wenn das alles funktioniert, sind Observability und Monitoring ein nützliches Add-On obendrauf.

DevOps entstand, weil es große Schwierigkeiten beim Betrieb von Anwendungen gab und Developer von diesem Thema wenig oder keine Erfahrung hatten. DevOps hatte das Ziel, Entwicklung und Operations näher zusammenzubringen. Anstelle von „Throwing things over the fence“ galt jetzt der Grundsatz: „You build it, you run it“. Damit änderte sich das Mindset von Softwareentwicklerinnen und -entwicklern: Statt sich hauptsächlich auf die Stabilität von Anwendungen zu konzentrieren, rückte die Automatisierung in den Fokus. DevOps-Teams versuchten, manuelle Tätigkeiten so weit wie möglich zu reduzieren.

Platform Engineering

Platform Engineering beginnt dort, wo diese grundlegende Automatisierung bereits vorhanden ist. Es geht darum, Transparenz über die bestehende Automatisierung zu schaffen und Self-Service zu ermöglichen. Platform-Engineering-Teams bauen Entwicklungsplattformen (Internal Development Platforms – kurz IDPs), die es ermöglichen, herauszufinden, welche Infrastruktur, Anwendungen und Deployments es bereits gibt und wie man sie nutzen kann. Außerdem ermöglichen sie es, Deployments im Self-Service durchzuführen.

In den DevOps-Tagen war das Idealbild, dass Softwareentwickler:innen Code-Änderungen ins Repository pushen und sich danach um nichts weiter kümmern müssen. Man erhält einen Build-Report oder eine Benachrichtigung – vielleicht per E-Mail, vielleicht auch gar nicht, oder nur eine Fehlermeldung über irgendeinen Kanal, falls der Build fehlgeschlagen ist. Das war’s. Die Idee war, alles zu automatisieren, was nach dem Push ins Repository passiert.
Platform Engineering hingegen zielt nun darauf ab, Softwareentwickler:innen in die Lage zu versetzen, tatsächlich zu sehen, was nach dem Push passiert. Es geht um mehr Sichtbarkeit, detailliertes Feedback und die Möglichkeit, selbst zu entscheiden, was gebraucht wird. Darüber hinaus geht es auch darum, die vorhandene Automatisierung aus der CI/CD-Pipeline für andere, verwandte Anwendungsfälle zu nutzen, die ähnliche Fähigkeiten erfordern.

Zum Beispiel könnten Softwareentwickler:innen mithilfe der IDP Entwicklungsumgebungen selbst deployen. Die Bereitstellung einer solchen Umgebung nutzt viele Automatisierungsbausteine aus der CI/CD-Pipeline, ist aber vom Push entkoppelt und ermöglicht, die Entwicklungsumgebung im Self-Service zu erstellen.

In Zeiten von Platform Engineering beginnen Softwareentwickler:innen den Arbeitstag damit, über die IDP eine Entwicklungsumgebung zu deployen. Dort werden Code-Änderungen vorgenommen. Nach dem Push können in der Plattform die Testergebnisse und der Status der CI/CD-Pipeline eingesehen werden. Wenn der Build oder die Tests fehlschlagen, sollte man in der Lage sein, im Self-Service detaillierte Informationen dazu zu erhalten. Zum Beispiel könnten sich Softwareentwickler:innen in die Testumgebung einloggen oder per SSH auf den Testserver zugreifen, um zusätzliche Logs einzusehen.

Anschließend können sie sich ein System für den Feature-Branch mit einer selbst gewählten Konfiguration bereitstellen, um die fehlerhafte Umgebung dort zu deployen und weiter daran zu arbeiten. All das sollte im Self-Service zu erledigen sein – ganz ohne die Hilfe eines DevOps- oder Platform Engineers in Anspruch nehmen zu müssen.

Die Realität

Natürlich sieht es in der Realität anders aus. Viele CI/CD-Tools bieten bereits heute ein hohes Maß an Transparenz. Und viele DevOps-Teams haben Softwareentwicklerinnen und -entwicklern bereits gewisse Self-Service-Werkzeuge zur Verfügung gestellt – und damit praktisch schon Platform Engineering betrieben, ohne es so zu nennen.

Wenn ein Unternehmen, das noch keine Automatisierung im Einsatz hat, mit Platform Engineering beginnt, muss es dennoch all die typischen DevOps-Aufgaben erledigen. Es muss eine CI/CD-Pipeline aufbauen. Es muss all die Automatisierung entwickeln, die dafür notwendig ist. Erst wenn etwas automatisiert ist, kann es im Self-Service angeboten werden.

Die Rebellion

Neben dem Fokus auf Self-Service ist Platform Engineering auch als Gegenbewegung oder sogar als eine Art Rebellion gegen DevOps entstanden. DevOps wurde von vielen so verstanden, dass es das Leben von Softwareentwicklerinnen und -entwicklern eher erschwert. „You build it, you run it“ bedeutete, dass von DevOps-Engineers erwartet wurde, sowohl die Fähigkeiten eines Entwicklers als auch die eines Operations-Experten mitzubringen.

Platform Engineering hingegen hat das Ziel, Dinge für Softwareentwickler:innen wieder zu vereinfachen. Es geht darum, Komplexität zu reduzieren, indem spezialisiertes Wissen über Deployment und Infrastruktur in ein dediziertes Team verlagert wird – ein Team, das diese Dinge als Services bereitstellt.

Golden Paths

Eine der größten Herausforderungen im Platform Engineering ist es, das richtige Maß an Abstraktion zu finden. Wie viele Details brauchen Softwareentwickler:innen, um ihre Arbeit gut machen zu können? Deshalb dreht sich im Platform Engineering vieles um das Konzept der sogenannten „Golden Paths“: Vorlagen oder dokumentierte und unterstützte Vorgehensweisen, die einen klaren Weg vorgeben – aber gleichzeitig die Möglichkeit lassen, davon abzuweichen und z. B. eine Umgebung individuell anzupassen, wenn nötig.

Fazit

Die folgende Tabelle bietet einen strukturierten Überblick über die Unterschiede zwischen DevOps und Platform Engineering.

Kurz und knapp:

• DevOps ist ein kultureller und technischer Ansatz zur Verbesserung der Zusammenarbeit zwischen Entwicklung und Operations.
• Platform Engineering setzt DevOps im großen Maßstab um, indem es eine strukturierte Self-Service-Plattform für Softwareentwickler:innen bereitstellt.

Bereit für Platform Engineering? Jetzt herausfinden, wie Sie Cloudomation als IDP Backend Tool dabei unterstützen kann.