Skills, Tools und das richtige Mindset für DevOps

DevOps gilt als zukunftsträchtiger Prozessverbesserungsansatz zwischen Entwicklung und Betrieb von Software, der einen großen Vorteil für Entwickler, Betreiber wie auch Auftraggeber einer Software darstellt. Anknüpfend an den Ansatz der agilen Software-Entwicklung findet eine Transformation hin zum „digitalen Fließband“ statt – der Code wird unter Zuhilfenahme automatisierter Prozesse von der Idee bis zum Endprodukt durchgereicht.

Die Arbeitsschritte der Spezialisten sind miteinander verknüpft. Durch diese Methode herrscht eine hohe Produktivität, schnelleres Time-to-Market und somit ein besserer Durchlauf der initialen Software-Idee zum anwendbaren Produkt. Im Folgenden wird neben Tools und Zielen für das Thema DevOps auch das entsprechende Mindset vorgestellt, das für eine gelungene Umsetzung nötig ist.
Welche Geschäftsziele sich durch DevOps erreichen lassen
Oft spricht man beim Thema DevOps nur über die Tools und Umsetzungslösungen – doch sollte immer im Mittelpunkt stehen, wie sich die Geschäftsziele eines Software-Produkts besser (oder überhaupt) erreichen lassen. Denn DevOps spricht auch die Fachseite an, die das Software-Produkt in Auftrag gibt. Nachfolgend werden kurz drei Beispiele für Geschäftsziele genannt, die durch den DevOps-Gedanken erreicht werden können.
Ein mögliches Geschäftsziel ist die Robustheit der Software, die durch ein starkes Bewusstsein der Entwickler für den Verlauf der Wertschöpfungskette und ihren Einflussfaktoren ganz von selbst verstärkt wird. Das Wie und Wo des Software-Betriebs (Operations) sollte genauso im Fokus stehen wie die Architektur (Development). Es ist daher nicht abwegig, diese Form von gleichwertiger Anerkennung aus dem großen O von DevOps herauszulesen.
In Bezug auf die Wertschöpfung lässt sich der zeitliche Einfluss mit dem Stichpunkt Time-to-Market aufgreifen. Dessen Verkürzung ist ein weiteres Geschäftsziel. Klar strukturierte Abläufe und ein Bewusstsein über diese, sorgen beim „Fließband“ der agilen Software-Entwicklung für ein schnelles Umsetzen der fachlichen Anforderung. Eingespielte Teams sind dank DevOps zudem in der Lage, konstante Leistung zu erbringen und bei der Planung neuartiger Anforderungen zuverlässige Abschätzungen zu geben. Der ständige Blick über den Tellerrand in den Betrieb ermöglicht es dem Entwickler-Team, ein breites Wissen aufzubauen. Ein gutes Beispiel hierfür ist die folgende Situation: Fehlende Kenntnisse über langsame Backend-Systeme führen dazu, dass Leistungsengpässe erst beim Marktgang einer neuen Software-Anforderung erkannt werden. Im schlimmsten Fall ist das Produkt für den Marktgang untauglich. Dann bedarf es schnelle Nachbesserungen, die jedoch folgende Probleme aufwerfen:
  • Einerseits erlangen Entwickler erst dann genauere Kenntnisse über diese Systeme, wenn es zu erheblichen Ausfällen kommt: Dann fehlt die Zeit, sich genauere Gedanken über den Betrieb und das dortige Ökosysteme zu machen. Mit dem Ziel ein Pflaster für das Problem zu finden, wird intensiv, aber nur ad hoc, nach dem Ursprung gesucht. Was weiterhin ausbleibt, ist ein tiefer Einblick in den Bereich Operations.
  • Anderseits suchen die Verantwortlichen in dem Pflaster nur eine punktuelle Lösung für die Leistungsengpässe, aber sie führen keine komplette Überarbeitung der Software-Architektur durch. Denn Zeit und Ressourcen fehlen nach einem geplatzten Live-Gang. Die Fachseite drängt nämlich auf eine rasche Platzierung des Produkts auf dem Markt oder im Geschäftsablauf und gibt damit den Takt an. Die eigentlich notwendige Überarbeitung der Architektur fällt damit aus.

Es braucht den täglichen Kontakt mit der Denkweise der Systeme, um ein Gespür für sie zu entwickeln und dieses Wissen bei Architekturentscheidungen einfließen zu lassen.

An dieser Stelle soll erwähnt werden, dass modern aufgesetzte Software-Betriebe mit cloud- und container-basierten Plattformen (Kubernetes, OpenShift etc.) zwar bereits einen sehr transparenten DevOps-Ansatz haben und viele Schwachstellen eliminieren. Sie verhindern aber nicht die Probleme, die durch unbekannte schwache Glieder in der Betriebskette entstehen. Sind geeignete Monitoring-Werkzeuge verfügbar, um diese Glieder zu finden, müssen die Entwickler diese Werkzeuge auch bedienen und interpretieren lernen.

Ein drittes Geschäftsziel, das sich durch DevOps erreichen lässt, ist Nachhaltigkeit. Dieses schließt an die obigen zwei Geschäftsziele
Robustheit und Time-to-Market an. Durch besseres Wissen über die Wertschöpfung und an ihr beteiligten Parteien, entsteht ein qualitativ hochwertig aufgebautes Software-Produkt. Der DevOps-Ansatz erleichtert dadurch einem zukünftigen, neuen Entwickler-Team das Verständnis und die Wiederaufnahme von Arbeiten an diesem Code. Die oben erwähnten Pflaster werden dann seltener benötigt.

Mindset und Wissensaustausch sind die Erfolgszutaten für DevOps

Natürlich ist nicht gesagt, dass die genannten Probleme durch den DevOps-Gedanken nie wieder auftreten – sie werden aber deutlich seltener, sofern ein eingespieltes Team mit entsprechend hoher DevOps-Erfahrung beteiligt ist. DevOps ist gewissermaßen eine Anleitung dafür, wie ein Team einen solchen Grad an Abstimmung erreichen kann. Besonders das Mindset ist essentiell. Denn es sind die Team-Mitglieder, die vom Wissensaustausch getrieben sind, die den DevOps-Gedanken voranbringen. Das heißt, sie sind nicht nur bestrebt ständig Neues zu lernen und ihr Arbeitsumfeld bewusst wahrzunehmen, sondern teilen dieses Wissen auch mit ihren Mitmenschen. Der DevOps-Erfolg zeigt sich darin, dass ein Team sich gerne stetig verbessert und über sein Arbeiten reflektiert.

Zwei Hürden bei der Realisierung von DevOps: Management und Operations

Es ist viel zu beachten, um den richtigen Katalysator finden zu können, der den DevOps-Prozess ins Rollen bringt. So setzt ein täglicher Kontakt mit der Denkweise der Systeme eine Öffnung und Kooperationsbereitschaft bei zwei organisatorischen Einheiten einer Firma voraus, damit überhaupt der erste Schritt von Dev nach Ops passieren kann: Einerseits muss sich Ops in Richtung Dev bewegen und andererseits muss das Management diese Bestrebungen unterstützen.

Die Bereitschaft der Abteilung Operations, dass sie Ressourcen und eine Bühne zum kooperativen Austausch bietet, ist grundlegend, damit die Entwicklungsabteilung einen Überblick zum Thema Ops bekommt. Beim täglichen Geschäft ist es wichtig, dass Entwickler auf direktem Weg den Kontakt zu Personen im Betrieb finden können. Zudem muss es einfach und klar sein, sich in der Server-Landschaft per Login oder Frontend-Tools zu bewegen. Neben der Schaffung einer übersichtlichen technischen Basis muss der Betrieb auch bereit sein, die Rolle
eines Lotsen zu übernehmen und damit einem breiten Publikum für Support-Anfragen bereitstehen. Dem entgegenkommend müssen Entwickler fähig sein, Einblicke in Schnittstellen und Konfigurationen ihres Software-Produkts zu geben. All dies kann nur dann funktionieren, wenn das Management den Wandel der Verantwortungen sowie das Ineinandergreifen der zwei klassisch getrennten Abteilungen Entwicklung und Betrieb bevollmächtigt.

Diese Werkzeuge erleichtern die Arbeit

Eine technologische Entwicklung, die DevOps erheblich erleichtert, ist Virtualisierung. Der von Kief Morris geprägte Begriff „Infrastructure-as-Code“ steht für die neuen Möglichkeiten, die sich Entwicklern im Cloud-Zeitalter bieten. Dank einer virtualisierten Infrastruktur muss kein direkter Zugriff mehr auf die Hardware erfolgen. Ganze Server können per Programmierzeile ausgeführt, dupliziert oder gelöscht werden. Zudem möglich wird eine zentrale Verwaltung des Quellcodes mit Versionierung sowie automatisiertes Testen der Konfiguration von virtuellen Maschinen und den entsprechenden Deployments. Besonders die Automatisierung hilft den Zeitaufwand bei Entwicklern und Betreibern zu senken. Für DevOps sind vor allem die folgenden Tools bei der Verknüpfung von Entwicklung und Betrieb hilfreich:

  • Virtualisierungslösungen wie VirtualBox sind das A und O gelungener DevOps. Sie helfen den Entwicklern dabei, ihren Code auf lokalen virtuellen Maschinen zu testen. Damit lässt sich bereits in der Entwicklung testen, wie die Server-Umgebung auf die Software reagiert.
  • Automatisierungslösungen wie Puppet, Vagrant oder Ansible unterstützen Entwickler und Betreiber dabei, sich auf die wesentlichen Aspekte ihrer Aufgaben zu konzentrieren, indem sie routinemäßige Prozesse selbst übernehmen. Dies lässt sich fürs Untersuchen, Testen und Ausführen sowohl auf Software- als auch auf Infrastrukturseite anwenden.
  • Container-Plattformen wie Docker helfen bei der Bereitstellung von Containern, d.h. lauffähiger virtueller Zusammenfassungen einzelner Anwendungen – mitsamt allen Bibliotheken, Hilfsprogrammen und sonstigen Daten, jedoch ohne ein Betriebssystem. Container können im Umfeld eines Host-Betriebssystems gestartet werden und sind daher ressourcenschonender als eine komplett virtualisierte Anwendungsumgebung. In Verbindung mit der eingebauten Standardisierung in Skalierung, Service-Discovery oder
    Load-Balancing (z.B. bei Docker-Swarm) ist das Arbeiten mit Containern für DevOps-Entwickler mittlerweile essentiell.

Welche Skills DevOps brauchen

Die von David Guest eingeführte „T-Shape“ gibt einen Anhaltspunkt: Die vertikale Säule des Buchstabens „T“ symbolisiert die Spezial-Fähigkeiten des Mitarbeiters in einem eingegrenzten Fachgebiet; der horizontale Balken symbolisiert die Fähigkeit zum transdisziplinären Arbeiten. Für DevOps ist eine enge Einbindung der Anforderungen der Betreiber- bzw. Infrastrukturseite notwendig. Deshalb ist für die Mitarbeiter vor allem die Horizontale wichtig. Generalisten mit Offenheit für einen neuen Ansatz und den entsprechenden Technologien sind gefragt. Der Umgang mit diesen lässt sich vergleichbar leicht erlernen, da manche von ihnen ohnehin einen überschaubaren Funktionsumfang besitzen oder sich auch in einer Basisversion einsetzen lassen. Ein ebenso wichtiger Skill ist die Offenheit für einen
Wissensaustausch und die Fähigkeit, den Mitmenschen im Team eine neue Technologie näherzubringen und ihren Fokus auf die relevanten Stellen zu legen.

Ähnlich wie das Megathema Agilität hat sich der DevOps-Ansatz als Schlagwort etabliert, hinter dem sich eine Sammlung von Anforderungen und Business-Problemen verbirgt. Bei der agilen Software-Entwicklung haben sich im Laufe der Zeit feststehende Methoden, Werkzeuge und Strukturen entwickelt und etabliert. Ein ähnlicher Prozess lässt sich bei DevOps feststellen. Dennoch sollte DevOps nicht mit einem Stellenprofil verwechselt werden. Auch wenn es mittlerweile Experten gibt, die sich auf DevOps spezialisiert haben, ist das Thema in einem Querschnitt angesiedelt und erfordert, ganz analog zur Agilität, ein Mindset, einen Kulturwandel. Gerade deshalb geht es nicht um einzelne Kompetenzen, Fähigkeiten oder gar Tools – DevOps ist eine radikal neue Art zu arbeiten.

Eine neue Stufe für die IT

Sowohl bei Entwicklern als auch IT-Verantwortlichen ruft der Begriff DevOps immer noch einige Fragezeichen hervor. Es führt aber auf lange Sicht nichts an dem Thema vorbei, denn der DevOps-Ansatz wird aller Voraussicht nach in den nächsten Jahren zum Industriestandard werden und ist in manchen Sparten bereits gängige Praxis. Damit DevOps zum Standard in Unternehmen werden kann, müssen Entwickler umlernen und sich stärker mit Fragen des Betriebs der Software beschäftigen. Dabei helfen die in DevOps etablierten Rollen, sowie Tools und spezifische Skills.

Insbesondere gilt es, all diese Zutaten so zu vermengen, dass die beteiligten Parteien Appetit darauf bekommen, die Realisierung des DevOps-Gedankens mitzugestalten. Die eingangs erwähnte Transformation hin zum „digitalen Fließband“ erinnert an die Einführung des Fließbands in den Automobilfabriken Henry Fords. Sie hat nicht weniger als eine Revolution in der industriellen Produktion ausgelöst. Eine ähnliche Revolution zeichnet sich derzeit in der IT-Welt ab.


Dr. Florian Zierer arbeitet seit 2016 bei der PENTASYS AG. Seine Schwerpunkte liegen in den Bereichen Continuous Integration und Automatisierung sowie in der Programmierung mit Java im Bereich Webapp-Entwicklung und Scala im Bereich Spark/Hadoop. Er interessiert sich besonders für die Qualitätssicherung in agilen Projekten und die Transition von klassischen
Systemlandschaften hin zu einer DevOps-Kultur.

Carolyn Molski


Leave a Reply