DevOps – Toolkultur oder Kulturtool? Teil 2

Wie das Leben so spielt: Zwei Kollegen besuchen zur selben Zeit zwei Konferenzen zum gleichen Themengebiet – und kehren mit sehr verschiedenen Eindrücken zurück:

DevOps und Continuous Delivery – Toolkultur oder Kulturtool?

KULTUR, ist der Tenor der Continuous Lifecycle – dazu mehr von Dominik Ufer hier. TOOLs, ist der Eindruck nach der Jax DevOps Konferenz, dazu mein Artikel:

---

Praxisteil: Tool-Kultur

Ich habe die JAX DevOps in London besucht. Die Konferenz ist ein Breitschlag über DevOps, Containerization, Cloud, Microservices und alles was mit Continuous beginnt.

Die Redner waren vornehmlich Pragmatiker und Praktiker, ihre Vorträge behandelten Erfahrungen und Tooling.

Was mir bei den Praxisvorträgen klar geworden ist: Seit 2009 die erste DevOps Konferenz stattgefunden hat, hat sich einiges am Begriff getan. Unter DevOps ist nicht nur mehr Kultur und Tool gemeint, sondern auch die Erfahrung, die jeder damit gemacht hat. Eine Pauschallösung gibt es nicht, jede Geschichte ist ein Unikat. Das ist auch nicht weiter schlimm, da wir auf erstaunlich viel zurückgreifen, was wir vorher auch schon gewusst und genutzt haben. Ein paar Beispiel-Anekdoten von der Konferenz:

Überziel

3.000 mal am Tag commiten! „Wow, will ich auch“, sagt meine Begeisterung! „Brauchen wir das überhaupt? Passt das zu meinen Zielen?“ spricht mein Kopf.

Venusfliegenfalle

Apropos Begeisterung: Besonders bei Cloud-Providers löst das große Potential und das Versprechen auf unendlich viel Ressourcen und Diensten mehr Hunger aus als nötig. Man läuft Gefahr, von einem Vendor-Lock in den nächsten zu laufen. Das geht auch einfacher: Stift raus, Excel an. Wie bei anderen Anschaffungen braucht es meist nur eine gute Excel-Kalkulation und eine unabhängige Systemarchitektur, um klarer zu sehen. Dazu einen einfachen Anwendungsfall mit möglichst wenig bis keinen Abhängigkeiten aussuchen und sich Stück für Stück in die Cloud Welt hineinarbeiten.

Wer beim Thema Vendor-Lock besonders sensibel ist, der versucht es mal Microservices. Sie passen auf jedes Zahnrad – egal ob beim Cloud-Provider oder Inhouse.

Babel

Wir haben sie ständig, sie kosten uns teils extrem viel Zeit und Nerven und trotzdem nehmen wir uns keine Zeit, sie zu entwirren: Sprachwirrungen!

Die langweilige Antwort des Pragmatikers: Einmalig Standards und Routinen aufsetzen, für Terminologie, Fehlerfälle, Verantwortlichkeiten und Regeltermine. Das ist nicht spannend aber nervenschonend für Dev und Ops, wenn es heißt: Die SW ist fertig und abholbereit.

Toolkultur

Eine Continous-Delivery-Pipeline wird für viel Geld von Externen gebaut, abgenommen, einmal genutzt und dann nicht wieder angefasst. Was hat gefehlt? Einfache Antwort auch hier: Erst muss die Akzeptanz hergestellt werden, dann hat es eine Chance, genutzt zu werden. Hier merkt man auch, ob es eventuell eine Kulturänderung braucht, da es dem Thema an sich an Zustimmung fehlt. Vielleicht geht es nicht um Offenheit gegenüber DevOps? Sondern darum, dass die existierende Toolkultur schon funktioniert.

Zitat: “CD is not a marathon, it’s a journey… and maybe you need a organisational change.”

Kulturtool

Die viel zitierte Kulturdiskussion wird teils politisch von oben heruntergebetet und versandet – auch weil dauerhaft der politische Wille fehlt. Denn eins ist sicher: Es geht auch ohne Kulturwandel, nur dann schleppender. In der Praxis werden Dev und Ops nicht von heute auf morgen Best Buddies. Das braucht Vorbilder, Menschen die für das Thema brennen und ein ständiges mit einander wollen.

Den interessantesten Lösungsansatz lieferte Eduards Sizovs (hier auf Twitter) mit “Beer Driven Diplomacy”: Man kann noch so viele Tools, Kulturprogramme und erfahrene Personen einpacken – die meisten Probleme lösen sich bei einem Bier.

---

Über den Autor