Hol Dir einen Kaffee, mach Dir entspannende Musik an, und begleite uns zur zehnten Folge von The Hüb. Diesmal teilt Marjan Bugarinović die wertvollen Erfahrungen, die er als DevOps Engineer bei Zühlke gesammelt hat.
„Willkommen bei The Hüb – einem Ort, an dem unsere Fachleute offen ihre Meinungen, Ideen, und Erfahrungen sowie ihr Wissen zur Branche, ihrer Zukunft und wichtigen Trends weitergeben.“
Was ist DevOps? Wie wichtig ist das? Welche Skills muss man als DevOps Engineer für die Projektarbeit mitbringen?
Hol Dir einen Kaffee, mach Dir entspannende Musik an, und begleite uns zur zehnten Folge von The Hüb. Diesmal teilt Marjan Bugarinović die wertvollen Erfahrungen, die er als DevOps Engineer bei Zühlke gesammelt hat.
Eine Definition beschreibt DevOps als gemeinsame Abläufe und Software-Tools, durch die Menschen sich besser koordinieren und zusammenarbeiten können, um bessere und zuverlässigere Produkte hervorzubringen.
Im Arbeitsalltag beschleunigen DevOps-Prinzipien den Gesamtprozess von der Programmierarbeit bis zur endgültigen Bereitstellung der Applikation beim Kunden. Es geht im Wesentlichen um die Integration von Softwareentwicklung und IT-Betrieb, DevOps wird häufig als Aufgabengebiet von einzelnen, spezialisierten Engineers oder eines Funktionsbereichs im Unternehmen gesehen. Mag sein, im Grunde ist DevOps aber eher eine Kultur, die das gesamte Team verinnerlicht hat.
Oft wird die Arbeit von DevOps Engineers mit derjenigen von Site Reliability Engineers (SRE) gleichgesetzt. SRE ist in der Tat eine Tätigkeitsbeschreibung, aber genaugenommen nur eine Form der DevOps-Implementierung. Site Reliability Engineering hat bestimmte DevOps-Prinzipien oder ‑Vorgaben zum Gegenstand, darüber hinaus aber auch noch zusätzliche Aspekte, die bei DevOps nicht so zentral sind. Man kann sich das so vorstellen, dass DevOps eine Art Schnittstelle ist, während SRE eine Klasse repräsentiert, die diese Schnittstelle implementiert.
Die erste und grundlegende Fähigkeit ist das Verstehen der DevOps-Praktiken und DevOps-Kultur.
Software Developers oder System Administrators haben bei der Umstellung auf DevOps schon einen gewissen Vorteil. Wenn Du programmieren kannst, werden Dir die Automatisierungsaspekte von DevOps leichtfallen. Andererseits bringen System Engineers etwas sehr Wichtiges mit: sie kennen nämlich die Infrastruktur, mit der reine Programmers oft nicht so viel am Hut haben. Ich würde deshalb sagen, dass diese beiden Kompetenzen Skill Nr. 2 und 3 sind, die DevOps Engineers haben müssen.
Das heißt aber nicht, dass Du als DevOps Engineer nur noch mit Automatisierung und Tools zu tun hast. Es ist keine Grundvoraussetzung, aber als DevOps Engineer solltest Du programmieren können, denn dadurch wird vieles leichter. Mit Infrastruktursystemen musst Du Dich allerdings richtig gut auskennen.
Die frühere Kluft zwischen Softwareentwicklung (Development oder „Dev“) und IT-Betrieb (Operations oder „Ops“) besteht teilweise immer noch. Die ist eigentlich erst überwunden, wenn wir die Software Engineers im IT-Bereich nicht mehr System Administrators, sondern DevOps nennen. Wir arbeiten darauf hin, indem wir Leute einstellen, die sich in Theorie und Praxis mit DevOps auskennen. Sie schulen dann den Rest des Teams – auch in der Praxis, indem sie sich an der Anwendung von DevOps-Praktiken im Projekt selbst beteiligen. Die Idee bzw. das Ziel von DevOps ist es, die Softwareentwicklungszyklen zu verkürzen und mit einer Art Continuous Delivery eine hohe funktionale Qualität der Software zu gewährleisten.
Das hängt natürlich vom jeweiligen Projekt ab, aber meiner Meinung nach spielen bei komplexen Projekten DevOps Engineers von Anfang an eine zentrale Rolle, denn sie müssen die grundsätzlichen Entscheidungen über die Infrastruktur und die Organisation von Development Workflow und Pipeline treffen.
DevOps haben außerdem die Aufgabe, sich an der Konzeption und Umsetzung zu beteiligen, bestimmte Verfahren zu entwickeln und an der Definition verschiedener Umgebungen mitzuwirken. Und nicht zuletzt müssen sie natürlich für die Software Developers da sein und ihnen die Automatisierungstools nahebringen. Hier können DevOps Engineers wirklich unterstützen; vor allem kann die betreffende Person bestimmte Prozesse, Tools und Kulturaspekte festlegen und den Software Developers helfen, den gesamten Entwicklungs-Lifecycle zu nutzen und komfortabler damit umzugehen.
Es gibt einige Prinzipien, die im Grunde DevOps-Prinzipien sind, aber das gesamte Projekt betreffen. Im Detail findet man diese im „The DevOps Handbook“. Das sind:
Je nach Projekt und Kunde können wir mit diesem dritten Schritt auf organisatorischer Ebene anfangen. Dabei tun wir so, als ob wir – die Mitarbeitenden – im Organisationsprozess die Kunden sind und mit diesem Ansatz des tagtäglichen Experimentierens und kontinuierlichen Lernens arbeiten. Dabei überlegen wir uns, von welchen DevOps-Verfahren das Unternehmen profitieren würde.
Es gibt auch noch das Segment „DevOps Security“. Dabei geht es darum zu gewährleisten, dass die Programmierung des Codes in jeder Phase sicher ist. Für die Einzelperson ist das kaum möglich, deshalb entstand der Aufgabenbereich für DevSecOps, dessen Schwerpunkt die Sicherheit ist. Die Idee von DevSecOps ist, dass Sicherheit bei jedem Projekt ein integraler Bestandteil sein muss.
Das hängt von den individuellen Präferenzen und vom beruflichen Hintergrund ab. Das Wichtigste, was zukünftige DevOps Engineers mitbringen müssen, ist die Bereitschaft, jeden Tag dazuzulernen und auf Veränderungen zu reagieren.
Den Software Engineers empfehle ich für den Anfang immer ein paar Bücher zur Einführung in das Thema DevOps, zum Beispiel „Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation“ von Jez Humble und David Farley.
Wenn Du Dich nicht als Engineer mit DevOps befassen möchtest, sondern noch an der Uni bist, würde ich Dir „The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data“ empfehlen. Das ist zwar ein Roman und kein Sachbuch, aber trotzdem ein guter Ausgangspunkt, um die Herausforderungen des derzeitigen Workflows zu erkennen und sich Gedanken dazu zu machen, wie man am besten damit umgeht.
Ein Sachbuch, das ich Dir ans Herz legen würde, ist das schon erwähnte „The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations“. Mir hat dieses Buch geholfen, einige der Grundsätze von DevOps zu verstehen – was DevOps eigentlich ist und wie ich das in mein Projekt einbringen kann.
Anfangs habe ich nicht eingesehen, dass ich mich mit DevOps auseinandersetzen soll, nur weil es ein Trend war. Was ich aber interessant fand, war der Gedanke, dass ich durch DevOps in der Lage sein würde, am Entstehungsprozess von etwas Hochwertigem mitzuwirken, und das auf eine sehr schnelle und elegante Weise. Das hat mich motiviert. Also habe ich „The DevOps Handbook“ gelesen und mich dann ein wenig mit Bash-Scripting in Python auseinandergesetzt. Anschließend habe ich mich in diverse Tools zur Infrastrukturautomatisierung und virtuelle Maschinen für die Softwareentwicklung vertieft. Außerdem habe ich mich mit bestimmten CI/CD-Tools wie GitLab, GitHub, Azure DevOps, Jenkins usw. beschäftigt.
Was mich sehr interessiert und was eng mit dem kontinuierlichen Feedback zusammenhängt, ist die Beobachtbarkeit. Das und das Kubernetes-Ökosystem sind die beiden Dinge, die mich derzeit am stärksten beschäftigen.
Für mich ist Beobachtbarkeit eine Möglichkeit, wie ein System, das wir entwickeln oder entwickelt haben, kontinuierliches Feedback liefern kann. Das heißt, dass wir bestimmte Tools und Verfahren anwenden müssen, durch die wir die Leistung der Applikationen und der Infrastruktur überwachen und vor allem aber auch sehen können, wie der Code ausgeführt wird. Man kann auch Rückverfolgbarkeit sagen.
Kubernetes sehe ich als wichtigen Baustein für zukünftige Infrastrukturen: Man muss sich nicht mehr darum kümmern, wo die Anwendung läuft, sondern nur noch um ihre Programmierung. Das heißt natürlich nicht, dass Kubernetes-Systeme und -Architekturen immer und überall die beste Lösung sind, auch wenn leider viele der Meinung sind. Ich finde aber, dass wir uns mit unseren Systemen an der Kubernetes-Architektur orientieren sollten.
Dazu kommt natürlich die kontinuierliche Arbeit mit Cloud-Anbietern wie Azure, AWS und Google Cloud, die ich sehr spannend finde.
Außerdem führe ich in letzter Zeit immer häufiger Vorstellungsgespräche und habe festgestellt, dass auch der Recruiting-Prozess ein sehr interessantes Gebiet ist.
Vor allem gibt es ja in Vorstellungsgesprächen keine „falschen“ Antworten, vielmehr ist jede Antwort auf ihre eigene Weise relevant. Es ist sogar wichtig, wenn ein Kandidat oder eine Kandidatin eine Antwort gibt, die gar nichts mit der Frage zu tun hat. Daran, wie sie antwortet, erkennt man, ob die Person lernbereit ist und Niederlagen wegstecken kann – das heißt, ob sie Situationen, in denen sie scheitert, auch etwas Positives abgewinnen kann, weil sie das in ihrem Lernprozess voranbringt. Wichtig ist auch, dass die Person nicht nur fachlich top ist, sondern auch in der Lage, positives oder konstruktives Feedback zu geben und selbst anzunehmen. Das gehört zu den Dingen, auf die wir großen Wert legen, und natürlich geht es uns darum, dass die Person von sich aus die Initiative ergreift und lernbereit ist.
Marjan begann seine Laufbahn bei Zühlke im Dezember 2019 als Expert DevOps Engineer.
Seitdem war er an mehreren Projekten mit einem breiten Spektrum an Technologien, Frameworks und Programmiersprachen beteiligt, u. a. Kubernetes, AWS und Azure, Terraform, Python, Java, und Scrum als Vorgehensmodell, um nur einige zu nennen.
In seiner Freizeit liest der vielseitig interessierte Marjan viel oder hört Podcasts, wenn er sich nicht gerade durch Felsklettern fit hält.
