© Forgem/Shutterstock.com
Was in zehn Jahren DevOps-Bewegung alles passiert ist

Die erste Etappe einer langen Reise ...


Vor rund zehn Jahren kam der Begriff DevOps auf. Seitdem hat sich technisch einiges verändert. Außerdem gibt es ganz neue Kollaborationsansätze in der IT.

Im Jahr 2019 ist die DevOps-Bewegung zehn Jahre alt geworden. Die öffentliche Initialzündung war ein Vortrag von John Allspaw und Paul Hammond von Flickr auf der O’Reilly Velocity Conference 2009 [1]. In diesem Vortrag beschreiben die beiden die seinerzeit übliche Arbeitsteilung zwischen Softwareentwicklung (Dev) und -betrieb (Ops) folgendermaßen: „Dev’s job is to add new features. Ops’s job is to keep the site stable and fast.“ Sie argumentieren, dass beide Parteien das Business unterstützen sollten und diese Unterstützung nur durch kontinuierlichen Change möglich sei. Damit der kontinuierliche Change aber nicht zu Fehlern und Ausfällen führt, brauche es neue Tools und kulturelle Ansätze („Lowering the risk of change through tools and culture“).

Wie sehr sich die Welt von einem Tag auf den anderen ändern kann, ist im Jahr zuvor am Beispiel der Bank Lehman Brothers und der weltweiten Finanzkrise nur allzu deutlich geworden. Die Wellen dieser Krise reichen weit bis ins Jahr 2009 hinein. In diesem Jahr meldeten unter anderem der Autohersteller GM und Arcandor AG (ehemals KarstadtQuelle AG) Insolvenz an. Einzig die politische Lage wirkt aus heutiger Sicht stabiler: Mit Barack Obama wurde ein Hoffnungsträger als US-Präsident vereidigt und aus der Bundestagswahl gingen CDU und FDP mit einer eindeutigen Regierungsmehrheit hervor. Die schnelle Bildung von Zweiparteienkoalitionen ist heute seltener geworden.

Die IT-Landschaft dieser Tage war auch noch sehr viel klassischer als heute: Das iPhone ist erst zwei Jahre alt und beginnt gerade erst, die mobile Internetnutzung zu verändern. Das Hosting von Anwendungen findet in der Regel ganz klassisch in Rechenzentren statt. AWS ist erst ca. drei Jahre alt und Google startet mit der Google App Engine for Java [2]. Beide sind zu diesem Zeitpunkt noch keine echten Alternativen zum On-Premise Hosting. Das bedeutet auch, dass IT-Infrastruktur zu dieser Zeit noch ein erhebliches Investment darstellte. Meist wurden schon zu Beginn einer Softwareentwicklung die Hardwaresysteme für den späteren Betrieb dimensioniert und bestellt. Die Kosten für diese Investition waren mindestens fünfstellige Eurobeträge.

diener_devops_1.tif_fmt1.jpgAbb. 1: Cover der Java-Magazin-Ausgabe 1.2009

Die Java-Community diskutierte im Jahr 2009 natürlich über die Übernahme von Sun Microsystems durch Oracle und darüber, welche Auswirkungen diese Entwicklung auf die Java-Plattform haben würde. Technisch beschäftigte sich die deutschsprachige Community im Java Magazin damit, ob REST oder SOAP für Web Services das richtige Paradigma wären (Abb. 1) oder ob man eher auf EJB 3.0 oder auf Spring 3.0 setzen sollte. OSGi war der Hoffnungsträger in Bezug auf feingranulare, modulare Architekturen, und im Enterprise-Bereich waren SOA und ESB die relevanten Themen.

Im Java Magazin und auf zahlreichen Konferenzen ließ sich beobachten, dass außerdem das Thema Agilität bzw. agile Softwareentwicklung mehr und mehr diskutiert wurde, aber noch viel erklärungsbedürftiger war als heute. In der Kolumne „Perspektivenwechsel“ im Java Magazin erhielten die Leser Tipps für die praktische Anwendung der noch relativ neuen Konzepte Scrum, Kanban, TDD oder XP. Die meisten agilen Ansätze blieben in der Realität des Jahres 2009 allerdings Insellösungen: Selbst wenn das Scrum-Team nach jedem Sprint ein Potentially Shippable Product Increment lieferte, schaffte es dieses Softwareartefakt allerhöchstens auf ein Entwicklungs- oder Testsystem. Die Auslieferung auf Integrations- oder gar Produktionssysteme fand viel seltener statt – oft nur einmal im Quartal.

Für diese Zeit war es revolutionär, dass die beiden Flickr-Mitarbeiter schon in ihrem Vortragstitel von zehn oder mehr Deployments am Tag (!) sprachen und eine Reihe von Tools und Eigenschaften ihrer Kultur vorstellten, um eine bessere Kooperation von Dev und Ops zu erreichen. Folgende Tooling-Aspekte zählten sie auf (Abb. 2):

diener_devops_2.tif_fmt1.jpgAbb. 2: Vorschläge aus der Präsentation von Allspaw und Hammond
  1. Automated Infrastructure: Entgegen der zu dieser Zeit gängigen Praxis (manuelle Installation) plädierten die beiden für eine Provisionierung der Infrastruktur mit Werkzeugen wie Chef oder Puppet.

  2. Shared Version Control: Die Skripte für die automatisierte Provisionierung der Infrastruktur sollten im selben Versionskontrollsystem wie der Anwendungscode liegen.

  3. One Step Build and deploy: Ebenso wie die Provisionierung der Infrastruktur sollten auch Deployments in einem automatisierten und vor allem nachvollziehbaren Prozess stattfinden („Wer hat was zu welchem Zeitpunkt deployt“).

  4. Feature flags: Die beiden argumentierten, dass man bei Webanwendungen andere Versionierungsansätze als bei Desktopsoftware brauchen würde, und plädierten für den Einsatz von Trunk Based Development und Feature-Flags [3].

  5. Shared Metrics: Für diese Zeit revolutionär war auch der Ansatz, gemeinsame Systemmonitoringwerkzeuge für Entwicklung und Betrieb bereitzustellen.

  6. IRC and IM robots war ein Vorläufer dessen, was später als ChatOps bekannt wurde.

Der wichtigste Ratschlag in kultureller Hinsicht war der des gegenseitigen Respekts. Nach wie vor bedeutet das insbesondere, mit Vorurteilen aufzuräumen und die jeweils andere Seite als Experten auf ihrem Gebiet anzuerkennen. Diese Expertise soll aber nicht zu geheimem Herrschaftswissen führen, vielmehr sollen alle Aspekte der Entwicklung und des Betriebs transparent werden (Einbindung von Ops in Featurediskussionen bzw. Einbindung von Dev bei Infrastrukturänderungen). Nur so entsteht Vertrauen, das unabdingbar für eine sinnvolle Kollaboration ist. Darüber hinaus sollten alle Beteiligten immer unterstellen, dass jeder sein Bestes für das Business gibt. Sie sind sich sicher, dass trotzdem Fehler passieren werden und es eine gesunde Fehlerkultur ohne Blaming geben muss.

diener_devops_3.tif_fmt1.jpgAbb. 3: Programm der ersten DevOps Days im Jahr 2009

Der Begriff DevOps tauchte in dem Flickr-Vortrag noch nicht auf, tatsächlich wurde das Thema noch im Jahr 2008 eher unter dem Begriff „Agile Infrastructure“ oder „Agile Systems Administration“ diskutiert. Der Begriff DevOps entstand später im Jahr 2009 auf einer Konferenz in Gent. Inspiriert durch den Vortrag von Allspaw und Hammond sowie durch seine eigenen Erfahrungen rief Patrick Debois die DevOps Days ins Leben [4]. Auch dort ging es sowohl um Tooling bzw. Automatisierung als auch um kulturelle Aspekte der Kollaboration (Abb. 3).

DevOps ist mehr als Tooling ...

Mit steigender Popularität wurde der Begriff DevOps immer häufiger mit Tooling bzw. Automatisierung gleichgesetzt – vor allem in den Marketingbotschaften. Dabei ging es aber in der Regel nicht um Tooling-Prinzipien, wie Allspaw und Hammond sie beschrieben hatten, sondern eher um das Versprechen, man müsse nur Tool XYZ einsetzen, um erfolgreich zu sein. Wie so oft stellte sich auch hier schnell Ernüchterung ein. Eine bessere Kollaboration und damit häufigere, stabile Softwareauslieferungen lassen sich eben nicht einfach durch ein Tool erreichen.

Das Buch „The Phoenix Project“ [5], das mittlerweile als Standardwerk der DevOps-Bewegung gilt, beschrieb einige Jahre später sehr anschaulich, dass DevOps vor allem einen Kulturwandel bedeutete. Die Geschichte spielt in der fiktiven Firma Parts Unlimit...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang