Spezialisten kontra Nachwuchskräfte Wie DevOps vom Generationenkonflikt profitiert

Wir befinden uns zwar erst seit ein paar Jahren in der DevOps-Bewegung – jedenfalls unter diesem Namen – aber schon jetzt unterscheiden manche zwischen erfahrenen DevOps-Spezialisten und -Neulingen. DevOps wird in diesem Kontext allerdings falsch verstanden.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

Ein Beweis hierfür sind zum Beispiel entsprechende Jobangebote. Die Nachfrage nach DevOps-Ingenieuren ist höher als nach anderen Profilen. Das könnte für DevOps-Ingenieure eigentlich erfreulich sein – wenn sie denn existierten. Denn: Was ist der Unterschied zwischen einem System-Administrator und einem DevOps-Ingenieur? Genau, es gibt keinen.

Dieselben Teams, die in der Vergangenheit für den operativen Betrieb, CI/CD-Prozesse oder Automation verantwortlichen waren, wurden in DevOps-Teams umbenannt. Alles ist das gleiche, nur der Name ist unterschiedlich. Das wird dem Begriff von DevOps aber nicht gerecht.

Bei DevOps geht es darum, die Lücke zwischen Entwickler- und Operations-Teams zu schließen. Silos sollen entfernt und das Know-how der beiden Bereiche in ein neues, eigenständiges Team zusammengefasst werden. DevOps könnte man auch als eine Weiterführung agiler Konzepte betrachten.

Agile versuchte bereits, einige der Silos zu entfernen. Wenn wir die Teams ignorieren, die Agilität nur „vortäuschen“, arbeiten Business-Analysten, Entwickler und Tester als eine kohärente Gruppe. Sie alle sind Mitglieder des gleichen Teams. Horizontale Abteilungen wurden durch Teams ersetzt, die sich auf Produkte fokussieren – und nicht nur auf ihre Spezialgebiete.

DevOps als erweitertes agiles Konzept

Agilität sollte und wollte die Zeiteinbußen beseitigen, die durch Übergaben von Projekten von einer Abteilung zur anderen entstehen. Das Problem bestand aber darin, dass Agile das Operations-Team, Systemadministratoren und andere Fachkenntnisse, die in späteren Phasen des Softwareentwicklungs-Lebenszyklus anfallen, nicht in die praktische Umsetzung miteinbezogen hat.

DevOps versucht, genau diesen Sachverhalt zu lösen, indem frühere vom Prozess ausgeschlossene Spezialisten integriert werden. Dies beinhaltet den Aufbau autonomer und autarker Teams, bestehend aus Operators und Systemadministratoren. Ein Team sollte für einen Service vom Start bis zum Ende (Software-Verteilung und Überwachung) verantwortlich sein.

Die jeweiligen Rollen sind im Rahmen des Agile Manifesto umbenannt worden, zum Beispiel wurde aus einem Project Manager ein Product Owner. DevOps hingegen sieht eine Änderung der Bezeichnung nicht vor. Alles bleibt so wie es ist, jedoch steht jetzt das Produkt im Fokus, um das sich wiederum das Team bildet. Es gibt daher keine Zugehörigkeit zu einer bestimmten Abteilung und das Ziel jedes Teammitglieds ist das gleiche: ein Produkt mit hoher Qualität und Schnelligkeit in die Produktion zu bringen.

Wie Routiniers und Nachwuchs voneinander lernen

DevOps definiert keine Rolle, sondern meint einen Kulturwandel. Aus diesem Grund ist die Frage nach Vor- und Nachteilen junger und erfahrener DevOps-Spezialisten im Grunde falsch. Es sollte daher besser heißen: Die Vor- und Nachteile junger und erfahrener Spezialisten allgemein. Dies führt zu dem Ergebnis, dass man sich rein auf die Expertise fokussiert.

Unerfahrene Mitarbeiter verhelfen Unternehmen oftmals zu neuen Sichtweisen. Es sei denn, sie werden sofort in eine Kiste gesteckt, und es ist ihnen nicht erlaubt, ihre Gedanken mitzuteilen. Neue, weniger erfahrene Mitarbeiter sind durch ihre Vorkenntnisse noch nicht eingefahren und schauen oftmals noch über den Tellerrand hinaus. Da sie auch nicht die alten Vorgehensweisen kennen, sind sie im Hinblick auf unterschiedliche Arbeitsweisen flexibel.

Jeder von uns, der bereits seit längerer Zeit in derselben Umgebung arbeitet, neigt dazu, selbstgefällig zu werden. Man hat natürlich den „besten Weg“ gelernt, seine Aufgaben zu erfüllen. Es gibt nur ein Problem: Der eine richtige Weg existiert nicht – und falls doch, ändert dieser sich ständig. Best Practices haben in der Regel eine sehr kurze Lebensdauer, da sich die Technologie und die Prozesse mit zunehmender Geschwindigkeit verändern.

Unser Hang zur Routine hindert uns daran, neue und bessere Wege zu beschreiten, um unsere Arbeit zu erledigen. Fortschritte werden oft von denjenigen erbracht, die in der Lage sind, ungezwungene Ideen zu haben. Diese Leute sind oft Neulinge. Dennoch haben auch sie ihre eigenen Probleme: Weniger Erfahrung bedeutet, dass wir (noch) nicht über das nötige Wissen verfügen, um in komplexen Umgebungen zu arbeiten. Alles scheint einfacher zu sein, als es am Ende wirklich ist. Hier ein paar Beispiele:

Irrtum: „Diese Anwendung kann in wenigen Wochen in Go umgeschrieben werden.“

Realität: Wahrscheinlich nicht. Es sei denn, es handelt sich um eine sehr einfache Anwendung.

Irrtum: „Wenn wir zu Microservices übergehen, sind alle unsere Probleme weg.“

Realität: Definitiv nicht. Die Migration von Anwendung(en) auf eine Mikroservice-Architektur könnte an sich schon ein sehr bedeutendes Projekt sein. Außerdem, selbst wenn das Projekt fertig ist, sind längst nicht alle Probleme beseitigt.

Irrtum: „Docker wird unsere Skalierbarkeitsprobleme lösen.“

Realität: Ja und nein. Wenn es richtig eingesetzt wird, hilft es. Wenn die Umgebung aber beschränkte Ressourcen hat, kann Docker diese Probleme nicht lösen. Und was ist mit Dev vs. Test vs. Ops? Wenn alle drei Teams Docker nicht akzeptieren, dann ist alles umsonst. Zudem ist es keine DevOps-Umgebung, wenn die Teams so stark voneinander getrennt sind.

Es ist nicht verwunderlich, dass solche Vorschläge von weniger erfahrenen Fachleuten kommen. Sie hatten noch nicht die Chance, die Komplexität eines Systems wirklich zu erfassen. Auch wenn es sich um ein Projekt auf grüner Wiese handelt, das gerade erst begonnen hat, so zeigt uns die Erfahrung, dass es mit der Zeit immer umfangreicher wird und dass diese Komplexität frühzeitig berücksichtigt werden muss.

Das ist der Generationenkonflikt, der nicht nur in der Softwareindustrie zu beobachten ist. Weniger erfahrene Profis bringen eher neue Ideen zum Vorschein, haben aber nicht die Erfahrung, diese erfolgreich umzusetzen. Erfahrenere Menschen neigen dazu, sich mit ihren Sichtweisen einzumischen und Innovationen abzulehnen.

Viktor Farcic

Wir brauchen beides. Wir müssen Erfahrung mit Innovation verbinden. Wir müssen das Neue und das Alte zusammenführen, wenn wir uns verbessern und auf dem heutigen Markt bestehen wollen. Andernfalls stehen wir vor dem Aus, weil neue und bessere Denkweisen entstehen. Und ob es nun DevOps oder etwas anderes ist, wir müssen offen sein für neue Ideen und neue Wege, diese umsetzen.

* Viktor Farcic ist Senior Consultant bei CloudBees.

(ID:45087935)