Was bedeutet DevOps heute?

Eng verknüpft

Konstantin Diener

Viele Firmen verstehen unter DevOps reines Tooling. Dabei ist die kulturelle Veränderung sehr viel wichtiger. Aber auch beim Tooling hat sich in den letzten Jahren einiges verändert.

Tools und Technik sind immer noch ein erhebliches Element dessen, was heute als DevOps gilt. Inzwischen findet das Tooling in der Cloud statt. Daneben hat in den letzten zehn Jahren die Größe der Deployment-Einheiten stark abgenommen. Gleichzeitig ist ihre Anzahl enorm gestiegen (siehe Abbildung 1). Bestand damals eine Anwendung in der Regel aus einer oder wenigen Deployment-Einheiten, zum Beispiel einer EAR-Datei, sind Anwendungen heute aus vielen Dutzend kleiner Einzelteile aufgebaut. Bei diesen kleinen Einzelteilen handelt es sich oft um Microservices. Ein sehr kleiner Service kapselt eine oder wenige fachliche Problemstellungen (Bounded Context), enthält technisch aber alle Bestandteile, wie einen Webserver und so weiter, um autonom einsatzfähig zu sein.

Annäherungsprozess

DevOps entstand vor etwa zehn Jahren, als die IT noch von einer strikten Trennung zwischen Softwareentwicklung (Dev) und Betrieb (Ops) geprägt war. Dem Betrieb oblag nicht nur die Bereitstellung der Software, sondern auch die der zugrunde liegenden IT-Infrastruktur wie Server, Speicher und Netzwerke. Die großen Cloud-Anbieter wie AWS steckten noch in den Kinderschuhen. Daher handelte es sich bei diesen IT-Infrastrukturen um dedizierte Systeme, die in großen Rechenzentren oder bei den jeweiligen Firmen vor Ort betrieben wurden.

Zu dieser Zeit begannen erste Unternehmen, agile Softwareentwicklungsmethoden wie Scrum, Kanban oder Extreme Programming einzusetzen. Man hatte erkannt, dass kontinuierliche Produktinnovationen wichtig sind, um am Markt bestehen zu können. Allerdings war beim Ausliefern der Software ins Produktivsystem meist Schluss mit der neuen Geschwindigkeit. Da nutzte es wenig, dass das Scrum-Team alle zwei Wochen eine neue Softwareversion ausliefern konnte. Für die Installation mussten diese Softwareversionen in eine andere Abteilung übergeben werden. Die Übergabe war langwierig und für alle Beteiligten sehr mühsam. Regelmäßige Softwarelieferungen empfanden die Betriebsmitarbeiter als Belastung, weil jede Änderung die Stabilität des Systems gefährdet. Die Softwareentwickler wiederum kannten die Konfiguration des Produktivsystems und das Verhalten ihres Produkts dort gar nicht.

Ausgehend von einer Konferenz in Gent entstand eine Philosophie, die sich eine sehr viel stärkere Kollaboration zwischen Dev- und Ops-Mitarbeitern zum Ziel gesetzt hat. Softwareänderungen sollten häufiger und stabiler stattfinden können.

DevOps ist viel mehr als nur Tooling

Nicht wenige, die seitdem auf den DevOps-Zug aufgesprungen sind, waren schnell ernüchtert. Die versprochenen Ergebnisse rund um häufigere und stabilere Softwareänderungen wollten sich nicht einstellen. In der Regel hatten Firmen eines der ersten „DevOps-Tools“ als Heilsbringer eingeführt. Es hatte möglicherweise das ein oder andere vereinfacht, aber die großen Verbesserungen waren ausgeblieben.

Spätestens durch das Buch „The Phoenix Project“ [2] wurde klar, dass die DevOps-Philosophie sehr viel mehr umfasst als nur Technologien und Tooling. Das Buch beschreibt die Geschichte des fiktiven Unternehmens Parts Unlimited. Hier stehen nicht Tooling und Technologien im Vordergrund, sondern Praktiken, Prozesse und die Unternehmenskultur.

In dieselbe Kerbe schlägt der „2018 State of DevOps Report“. Sich mit dem Thema DevOps zu beschäftigen, ist für die Autoren eine Reise – die DevOps Journey. Als Voraussetzung für diese Reise und als Reisebegleiter sind die Praktiken aus dem CAMS-Modell unabdingbar: Kultur (Culture), Automatisierung (Automation), Metriken (Measurement) und selbstverständliches Teilen von Erfahrungen (Sharing). Nur einer der vier Aspekte hat etwas mit Tooling zu tun (siehe Abbildung 2).

Das CAMS-Modell (Abb. 2)

Anzahl und Größe von Deployment-Einheiten 2009 und 2019 (Abb. 1)

Beschleunigt wurde diese Entwicklung durch das Aufkommen von Containertechniken, in erster Linie Docker. Dieser Technikansatz ermöglicht es erstmals auf einfache Weise, alle notwendigen Softwarezutaten transportierbar in einen Container zu packen und ohne Installation auf einer beliebigen Basisplattform auszuführen. Besonders mächtig wird er dadurch, dass es eine Vielzahl verschiedener fertiger Container-Images gibt (gängige Betriebssysteme, Application-Server etc.), die sich einfach um eigene Komponenten und Konfigurationen ergänzen lassen.

Ein zweiter Turbo für die immer kleinteiliger werdenden Anwendungen sind die wachsenden Technikangebote der Anbieter von Public Clouds und Managed Services. War es vor zehn Jahren noch absolut üblich, einen Datenbankcluster, einen Suchindex oder eine NoSQL-Datenbank selbst aufzusetzen, zu betreiben und zu patchen, kommen heute immer öfter Managed-Service-Angebote zum Einsatz. Einige behaupten, was vor zehn Jahren die Suche nach einer passenden Java-Bibliothek war, sei heute die Suche nach einem passenden Managed-Service-Angebot. Für alle denkbaren Anwendungsfälle existierten entsprechende Managed Services. Dazu gehören etwa Messaging, Sprachausgabe, Caching, Authentication, relationale Datenbanksysteme, NoSQL-Datenbanken, Suchindizes, File Storage und viele mehr. Diese Services können zu einem sinnvollen Preis angeboten werden, weil sie in der Regel auf Basisservices der großen Public-Cloud-Anbieter wie AWS basieren.