In diesem (ehemals) kurzen Blog sollen die Begriffe DevOps, GitOps und Plaform Engineering beschrieben und gegenübergestellt werden. Ist DevOps jetzt tot und Platform Engineering «the new kid on the block»? Oder brauchte es einfach mal wieder ein re-branding eines bestehenden Konzepts? Und was hat «GitOps» damit zu tun? Wir werden sehen!
DevOps
DevOps ist keine Technologie. Das ist ein kurzer Satz, den es sich dennoch zu merken gilt. Es ist viel mehr ein Kulturwandel der darauf abzielt die verschiedenen Lager von IT-Teams miteinander zu verknüpfen und die Zusammenarbeit zu verbessern.
Klassischerweise sind diese Lager in «Entwicklung» und «Betrieb» unterteilt. Gemäss des DevOps Ansatzes sollen die Barrieren zwischen den Lagern abgebaut, voneinander gelernt und zusammengearbeitet werden. Wenn jede Person das Gefühl bekommt aktiv an den Projekten mitzuwirken, wird ein gemeinsames Verantwortungsbewusstseins etabliert, welches sich positiv auf den Gesamterfolg, die Zufriedenheit und Velocity auswirkt.
Daraus resultierend haben sich im DevOps Umfeld eine Reihe von Praktiken wie Continuous Integration, Continuous Delivery, Testautomatisierung,
Infrastrukturautomatisierung, Monitoring (uvm.) etabliert. Das heisst nicht, dass es nicht vorher bereits Infrastrukturautomatisierung oder Monitoring Lösungen gab. Darum geht es nicht. Viel wichtiger ist die effiziente Bereitstellung und reibungslose Zusammenarbeiten der verschiedenen Experten. Das ganze eventuell sogar innerhalb eines Teams.
Durch die etablierung dieser (und weiterer) Praktiken und den «Mindshift» der Organisation und aller Beteiligten, wird es Teams ermöglicht, Software schneller und zuverlässiger zu entwickeln, zu testen und bereitzustellen. Wenn etwas aus diesem Abschnitt mitzunehmen ist, dann folgendes: Der DevOps Ansatz versucht die zunehmende Komplexität von Systemen insbesondere durch einen Kulturellen wandel zu lösen. Natürlich spielen Technologien als ausführendes Hilfmittel eine zentrale Rolle in der Umsetzung.
GitOps
GitOps ist ein Ansatz zur Bereitstellung und Verwaltung Software und Infrastruktur. Das wohl offensichtlichste Merkmal ist, dass ein Git-Repository als «single source of truth» für die automatisierte Bereitstellung der Software und Infrastruktur (CI/CD) dient. Im Wesentlichen werden alle Applikationen und Infrastrukturkomponenten, die für das jeweilige Projekt notwendig sind, inklusiver ihrer Versionen (und ggf. weiterer Angaben) aufgeschrieben. Bei Änderungen an dieser «Bestandsliste», sorgen Pipelines (oder ähnliche Mechanismen) dafür, dass die Änderungen angewandt werden. Klingt eigentlich einfach, oder?
- Die Wahrheit steht im Repository – Jeder weiss, wo er/sie hinschauen muss
- Mehr als das, was im Repository steht, benötigt die Applikation nicht, um lauffähig zu sein
- Nicht nur die Software, sondern auch die benötigte Infrastruktur ist beschrieben
- … daraus resultiert, dass plötzlich die Entwicklung und der Betrieb eine gemeinsame Platform verwenden
- Ein Deployment ist ein commit (+push)! Das heisst zwangsläufig, dass es ersichtlich ist wer, wann und was auf welche Umgebung ausgerollt hat
- Auch Security-Themen finden Anwendung. Es lässt sich nun leicht über das Repository ermitteln, ob Teams ggf. veraltete Templates einsetzen oder Infrastrukturkomponenten einsetzen, die sie nicht mehr verwenden sollten
- Migrationen können deutlich schneller durchgeführt werden, wenn Konfigurationen an einer zentralen Stelle abgelegt sind
- ….
Platform Engineering
Für die Ungeduldigen unter uns, beantworten wir im ersten Satz zwei Fragen, die wir gelegentlich gestellt bekommen:
- Ist DevOps das gleiche wie Platform Engineering? Nein
- Ist DevOps tot? Nein
Aber es gibt etwas, das beide Ansätze eint: Der Bedarf durch die steigende Anzahl an Komponenten und Komplexität in Systemen.
Während DevOps versucht, das Problem der Zusammenarbeit und sinkender Velocity während der Softwareentwicklung aus einer kulturellen Perspektive zu lösen, versucht Plattform Engineering das Problem aus einem anderen Blickwinkel anzugehen: dem der Self-service.
Folgendes Beispiel soll dies unterschiedlichen Herangehensweisen verdeutlichen: Es soll eine Applikation umgesetzt werden, welche Daten aus einem Kafka-Topic konsumiert, verarbeitet und das Ergebnis in einer Datenbank ablegt. Die Kafka Resourcen werden mittels Strimzi (ein Kubernetes Operator), während die Datenbank in AWS RDS provisioniert werden soll. Leider gibt es einen Haken: Die Person, welche für die Umsetzung auserkoren wurden, kennt sich weder mit Strimzi, noch mit AWS RDS aus. Steigende Komplexität heisst zwangsläufig, dass nicht jede Person alles Wissen kann.
Der DevOps Ansatz könnte in in etwa wie folgt aussehen: Es wird entweder ein Team-Mitglied konsultiert oder ein Mitglied eines «cross functional» Teams unterstützt bei der Verfassung der Terraform/CloudFormation/CDK/… und Helm/Kustomize/Scaffold Templates, welche dann in einem Git Repository abgelegt und angewandt werden.
Der Platform Engineering Ansatz wäre, dass es ein «Internal Developer Portal» (idp) im Unternehmen existiert, bei welchem der/die jeweilige Entwickler/in über ein Self-Service sowohl die Datenbank, als auch die Kafka Resourcen anfragen kann, welche daraufhin erstellt werden.
Konstruieren eines integrierten Produkts (dem IDP), das Toolchains und Abläufe
umfasst, um die betrieblichen Anforderungen des gesamten
Softwareentwicklungszyklus zu erfüllen. Dieser Self-service Ansatz ermöglicht
es Entwickler/innen nach den aktuellen best-practices ein qualitativ hohes Level in sehr geringer Zeit bei der Umsetzung zu erreichen. Das IDP muss zwangsläufig gut gepflegt werden und verspricht im Gegenzug der ganzen Organisation einen potentiell hohen Geschwindigkeitszuwachs in der Softwareentwicklung.
Wichtig bei diesem Ansatz ist, dass nicht jeder Use-case abgedeckt werden kann und sollte. Es gibt immer Randfälle oder Entwickler/innen, welche ein aussergewöhnlich hohes Mass an Know-How in den jeweiligen Bereichen mitbringen. Das IDP stellt den Golden Path nach aktuellem Stand bereit – es ist kein Golden Cage.
Abschliessend noch ein paar exemplarische Anwendungsfälle für ein Internal Developer Portal:
- Übersicht über verfügbare Services und Verantwortlichkeiten (Service Catalog)
- Provisionieren von Cloud ResourcenProvisionieren von Kubernetes
- ResourcenBootstrappen von Projekten anhand Templates (bspw. mittels Cookiecutter)
- Automatisiertes Beantragen von Resourcen durch einen hinterlegtenWorkflow
- Bereitstellen von Pipeline-Beschreibungen beim Anlegen neuer Projekte
- Upgraden bestehender Projekte, bei Änderungen am Golden Path
- ….