Seite 2: Die frühen Jahre von DevOps [--] alles automatisieren

Inhaltsverzeichnis

Über die Jahre hat sich die DevOps-Definition weiter entwickelt. Anhand der regelmäßigen Vorträge auf diversen Konferenzen lässt sich das anschaulich nachvollziehen:

2011/12 ging es in "Practical DevOps" und "DevOps: Neue Arbeitsweise und Selbstverständnis in der IT" um die Erkenntnis, dass es nicht um die konkreten Werkzeuge und Softwaretools, sondern um die beteiligten Menschen geht, getreu dem Motto "The Tool is You".

2013 war das Rechenzentrum-Deployment-Tool yadt von ImmobilienScout24 ein Open-Source-Projekt, das durch seine andersartige Denkweise (ohne Puppet, Chef und CFEngine, die damaligen Platzhirsche im Automatisierungsmarkt) Aufsehen erregte.

2014/15 ging es in "DevOps Risk Mitigation – Test Driven Infrastructure" (Video) darum, wie sich die Risiken der neu gewonnen Freiheiten wieder einfangen lassen. Wenn alles automatisiert ist und jeder an der Automatisierung mitarbeiten kann, muss die Qualität der Software durch automatisierte Tests und einen testgetrieben Entwicklungsansatz sichergestellt werden. In dieser Zeit wurden bei IS24 sehr fortschrittliche Themen wie die ESX-Server-Installation oder die Schlüsselrotation für DKIM-Mailserver testgetrieben automatisiert, woran sich damals so gut wie niemand herangetraut hatte.

2015/2016 war klar, dass mit der fortschreitenden Automatisierung der Eigenbau im Rechenzentrum nicht mehr wirtschaftlich ist und sich daher die Migration auf öffentliche Cloud-Plattformen ("Hybrid Cloud – A Cloud Migration Strategy") lohnt, um an dort stattfindenden Innovationen zu partizipieren. DevOps war hier kein explizites Thema mehr. Stattdessen war es die Voraussetzung, um die Cloud-Migration überhaupt erfolgreich durchzuführen. Die jahrelange Professionalisierung im Rechenzentrum und der damit einhergehende Aufbau von Entwicklungsfähigkeiten in der Produktionsabteilung erlaubte bei IS24 in relativ kurzer Zeit die Entwicklung einer Self-Service-Cloud-Plattform auf Basis von AWS und vielen Open-Source-Tools. Im Rechenzentrum hatten die Entwickler bereits gelernt, für ihre Software selbst verantwortlich zu sein, sodass der Übergang zu AWS die natürliche Weiterentwicklung der Arbeitsweise darstellte.

DevOps in der Neuzeit – selbstverständlich

2016/2017 war der Autor bei Zalando tätig und DevOps war so selbstverständlich, dass niemand darüber sprach. Die Frage war jetzt eher, wie man DevOps-Gedanken jenseits der klassischen IT-Bereiche als Grundlage für eine neue Herangehensweise nutzen kann. "DevOps für Jedermann" und " A Workplace Strategy for the Digital Age" zeugen vom Fokuswechsel und der Selbstverständlichkeit von DevOps. Der Vortrag zeichnet einen Weg von DevOps in der IT zu einem neuen Denkansatz für den Umgang mit IT im Unternehmen. Dabei entwickeln sich Mitarbeiter von IT-Konsumenten zu beteiligten Nutzern, die den Computer als Werkzeug für sich entdecken können. Die interne IT stellt nicht nur gute Services zur Verfügung, sondern fokussiert sich auf die Produktivität und Zufriedenheit aller Mitarbeiter.

2018 – jetzt ist der Autor bei der Deutschen Bahn/DB Systel – geht es nicht mehr um die Frage, ob man DevOps macht, sondern eher darum, wann denn eine DevOps erfolgreich "fertig" sei. Seit 2016 migriert die Deutsche Bahn die Rechenzentren in die Cloud und die DB Systel schafft mit ihrer agilen Transformation die klassischen Führungsrollen ab. Hier spielt DevOps eine zentrale Rolle und ist mit Schlüssel zum Erfolg. "DevOps, Continuous Delivery & Cloud – Three Drivers of Enterprise Agility" (AWS Summit Berlin 2018) zeigt, dass sich diese Themen gegenseitig bestärken und ein erfolgreiches Unternehmen sie alle angehen muss, um wirklich erfolgreich zu sein.

Die Definition von DevOps hat sich jetzt spürbar gewandelt: Statt wolkigen Formulierungen rund um die agilen Prinzipien und eine tolle Zusammenarbeit auf Augenhöhe geht es jetzt um harte und messbare Zahlen, die den Fortschritt belegen. Die "Fünf Grundsätze, mit denen sich der Erfolg von DevOps messen lässt" (iX 12/2018 S. 104) sind eher konkret formuliert und lassen sich genau messen (Quelle: https://bit.ly/5pdops):

• Jeder Mensch benutzt für dieselbe Tätigkeit dasselbe Werkzeug.
• Kodifiziertes Wissen – alle tragen ihren Teil zu einer gemeinsamen Automation bei.
• Fehler machen ist erlaubt – für Dev und Ops gleichermaßen.
• Menschliche Schnittstellen werden durch automatisierte Entscheidungen und Prozesse ersetzt.
• Alle Beteiligten haben gegenüber den von ihnen genutzten Systemen die gleichen Rechte und Berechtigungen.

Die grundlegende Erkenntnis ist dabei, dass DevOps sich als Ergebnis aller Bemühungen einstellt und sich diese fünf Prinzipien nutzen lassen, um den Weg dahin transparent zu machen.

Heute liegt der Fokus vor allem darauf, wie das Unternehmen mit der allgegenwärtigen DevOps-Arbeitsweise zurechtkommt und wie sich alte Prozesse neu gestalten lassen. Während sich die Arbeitsweise verändert, bleiben die grundlegenden Anforderungen und Rahmenbedingungen in einem Unternehmen unverändert: Die Risiken für das Unternehmen müssen so gut, wie es geht, gemanagt und reduziert werden, die vollständige Nachvollziehbarkeit von Änderungen – die früher durch die manuellen Prozesse abgebildet wurde – ist weiterhin essenziell und die Dokumentationspflichten sind unverändert. Mit DevOps kommen jedoch neue Lösungsansätze ins Spiel: Governance und Compliance sind heute ein Automationsproblem, das sich im Sinne von Infrastructure as Code lösen lässt.

Schon 2009 genannte Mittel wie CI/CD Pipelines sind daher auch heute noch die Grundlage für die Lösungen. Im Rahmen der Pipelines werden zunehmend mehr Aufgaben mitgelöst, sodass am Ende eine "Compliant by Default"-Arbeitsumgebung (Continuous Lifecycle 2018) entsteht, in der die Produktion als "zertifizierter Raum" fungiert und sich nur erlaubte Änderungen deployen lassen.

Die "Automatisierte Governance" (Continuous Lifecycle 2019) garantiert dabei die Einhaltung der Regeln, während die Entwickler, die ja auch Betrieb machen, eigenständig und ohne auf andere warten zu müssen, arbeiten können:

DevOps ist normal

In der Realität vieler Unternehmen ist DevOps anscheinend noch nicht ganz normal, zumindest lässt sich das aus den Reaktionen des Publikums auf den Vortrag "DevOps ist normal" (DevOps Essentials 2019) schließen. Der Weg zu DevOps lässt sich mit dem Weg zum Führerschein vergleichen: Am Anfang lernt man die theoretischen Grundlagen und übt dann auf der Straße das Fahren, bis man es kann. Ein Fahrlehrer unterstützt dabei und verhindert das Schlimmste. So führen auch unterschiedliche Unternehmen derzeit DevOps in großem Stil ein: DevOps-Coaches unterstützen Teams in einer Transitionsphase und helfen den Entwicklungsteams, mit den neuen Verantwortlichkeiten im produktiven Betrieb klarzukommen.