Vom Full-Stack-Dev zum DevOp – eine lückenhafte Story ohne Pointe

Heute soll es auf meinem Blog mal um etwas Persönliches gesehen! Mal nichts ultra technisches (aber ohne geht natürlich nicht), sondern ein kleiner Auszug aus meinem beruflichen Werdegang. Wie wurde aus dem FullStack-Dev ein DevOps (aka Mädchen für alles).

Aller Anfang ist schwer

Angefangen habe ich meine berufliche Laufbahn naiv an den EDV-Schulen in Wiesau, mit einer schulischen Ausbildung zum Fachinformatiker. Nach 3 sehr langen Jahren dann endlich arbeiten. Vorher schon durch mein Fachpraktikum, in dem ich einen Teil meiner Abschlussprüfung gemacht habe, eine Firma kennengelernt, in der es sich aushalten ließ. Die Witt-Gruppe sollte es also sein.

Also gings erst mal darum alte PowerBuilder-Anwendungen (google it) auf moderne Webanwendung umzustellen. Danach kamen auch einige Neuentwicklungen oder Rewrites dazu. Alles in allem hat es sehr Spaß gemacht und mir viel Erfahrung gebracht. Aber aus einem unbekannten Grund fehlte mir etwas. Ich bin Techniker und das kam mehr oder weniger immer viel zu kurz.

Nach gut einem Jahr in der Festanstellung wurde durch eine Umstrukturierung eine neue Stelle frei. Ein Platz im Plattform-Team, als DevOp. Ich war hin- und hergerissen, jetzt schon aus der Entwicklung gehen? Bin ich bereit dafür? Als Softwareentwickler war ich schon ziemlich gut, dank Ausbildung und zahllosen Side-Projects. Also warum nicht? Fuck it, ich bin dabei! Nach gut einem weiteren Jahr konnte ich mich guten Gewissens als soliden Junior DevOp bezeichnen, nicht mehr weit entfernt vom Senior-Status, den ich auch bereits in der Softwareentwicklung genoss.

Man kann sich jetzt fragen – Wieso zum Henker ist der „kleine Junge“ schon so weit? - Aktuell 21 Jahre jung und schon wechselt er sein Tätigkeitsfeld. Na ja, nicht ganz, DevOp ist ja letztlich ein Hybrid aus Developer und Operator. Also schon mal stabile 50 %? Nicht ganz, letztlich ist die Mentalität weit wichtiger als die eigentlichen Skills.

DevOp sein scheint schwer

Automate everything, Infrastructure as Code usw.; tausende Tools – mehr „Konfigurieren statt Kompilieren“, wie ein Kollege zu sagen pflegte. Am Anfang wurde ich wirklich überrollt. Soviel neu und doch bekannt. Doch schnell lassen sich Parallelen erkennen, das ist gar nicht so weit weg von dem, was ich jetzt tue! Server habe ich ohnehin schon nebenbei immer etwas administriert, wenn auch auf die manuelle und detailverliebte Art. Plötzlich bin ich nicht mit meinem kleinen eigenen vServer konfrontiert, sondern einer wahren Bastion an VMs, Containern, Konfigurationen & Systemen. Da kommt man schnell an die Grenze des manuellen.

Ansible & Terraform zur Hilfe! Tools, die auf den ersten Blick für den Entwickler ungewohnt erscheinen. Ich soll den Zustand beschreiben? Wo sind meine guten alten if-Blöcke und Schleifen? Wo ist meine IDE, mit der ich komplexe Systeme programmieren und refactoren kann? Ein wahrer Schock, eine wahnsinnige Kopfsache, sich umzustellen.

Nach gut einem Jahr wurde das Umdenken zu einem „das macht ja tatsächlich Sinn“ und aus der „IDE-Losigkeit“ eine Sammlung von Plug-ins aus Marketplaces & Eigenbau. Das Monster gezähmt, die if-Blöcke nicht vergessen, sondern in State-Definitionen und Conditionals wieder gefunden.

Aber zum Glück habe ich der Softwareentwicklung nicht den Rücken kehren müssen, im Gegenteil es gibt immer wieder Stellen, wo ein gutes altes CLI-Tool oder ein Helper-Webservice erforderlich oder zumindest nicht abträglich ist. Nicht nur konfigurieren, sondern auch mal wieder kompilieren. Die Abwechslung macht es letztlich zu einem Job, den ich lieben gelernt habe. Weg von direkten Anforderungen des Fachbereichs bzw. Kunden hin zu technischen Herausforderungen. Natürlich wird man den Anforderungszwang nicht los, letztlich kann man die Infrastruktur ja nicht an der Realität vorbei provisionieren. Also na ja können schon, aber das wäre ja grober Unfug. Wobei das ja einige Big-Player in der IT immer wieder unter Beweis stellen. Speziell eine Firma mit drei Buchstaben aus Deutschland ist hier hervorzuheben.

Ein interessanter Paradigmen-Wechsel war auch hinweg von der ultimativen Wiederverwendbarkeit zugunsten der Lesbarkeit. Bei Konfigurationen ist es gelegentlich ratsam nicht alles so generisch zu machen, bis letztlich nur noch ein Parameter-Skellet übrigbleibt. Gerade in der Softwareentwicklung bin ich ein großer Fan von Abstraktion und enormer Wiederverwendbarkeit. Leider lassen sich nicht immer alle Paradigmen übernehmen, zumindest nicht ohne etwas angepasst zu werden. Heißt natürlich nicht, dass alles in Stein gemeißelt wird, wenn man mit DevOp-Technologien arbeitet, ganz im Gegenteil. Nur das „Gut und Böse“ verschiebt sich, am Anfang etwas ungewohnt, aber nach einer kurzen Eingewöhnungsphase erkannte ich schnell die Vorteile.

Der Schock zu Beginn, als ich das erste Ansible-Playbook sah, in dem alles redundant war und mehr oder weniger nach Spaghetti-Copy-Pasta aussah, war bei genauerer Betrachtung eigentlich genau das richtige Maß aus Redundanz und Abstraktion.

Unit-Test, wo bist du? Wo in der Software-Entwickung diverse Tests zur Tagesordnung und dem guten Ton gehören, scheinen im DevOp-Umfeld immer noch sehr viele manuelle Tests vorzuherrschen. Das ist schade und man muss hier auch anders denken wie bei der Softwareentwicklung. Vorallen das wie und was verschiebt sich extrem.

Wechsel zu Trusted Shops (und AWS)

Nach gut einem Jahr als DevOp in Bayern fing ich nun zum 1.10.2020 bei Trusted Shops an, dieses Mal gleich von Beginn als DevOp. Dadurch kommt wieder anderer Wind in die Sache. Neue Firma, Anforderungen und Kollegen und damit natürlich auch eine andere DevOps-Kultur. Nicht zuletzt raus aus der konservativen bayrischen Kleinstadt, nach NRW in den Großraum Köln.

Aktuell geht es hier viel um die (AWS-)Cloud – böse gesagt „some one else computer“. In a nutshell andere Terminologien und mehr oder weniger gut durchdachte Services, um bestehende Terminologien und Konzepte neu zu verpacken und automatisierbar zu gestalten.

Was sich zu Beginn als große Änderung herausstellte, war dann endlich doch überschaubar. Nicht alles, was komplex klingt, ist es am Ende des Tages auch. Mittlerweile bin ich hier auch gut zu Hause.

Allerdings schätze ich die Flexibilität von AWS von ganzem Herzen, gerade wenn man es gewohnt ist immer auf andere Abteilungen warten zu müssen, ist es toll einfach, mit Terraform dynamisch zu provisionieren, ohne lange warten zu müssen.

Letztlich auch ein wichtiger Grund, warum die Cloud, speziell AWS so populär ist. Wartezeiten werden hier drastisch reduziert oder gar komplett eliminiert.

Natürlich ist der Cloud auch nicht das Wunderheilmittel und es gibt viele kleinere Baustellen und komische Designentscheidungen. Doch man lernt, mit diesen zu leben und zu wachsen.

Abschluss

Letztlich ist ein DevOp also wirklich ein Hybrid aus Dev und Op, auch wenn je nach Tag der Anteil der Aufgaben etwas überlappt. Ich selbst betitle das ganze auch gerne als „professioneller Problemlöser für Infrastruktur“, den auf die Quintessenz heruntergebrochen, ist das mein „Daily Business“.

Das war es auch schon wieder. Die kurze, lückenhafte und zu detaillierte Geschichte wie ich zum DevOp wurde und was mich so aufgeregt hatte. Für den Fall, dass du eine ähnliche Story hast, würde ich mich freuen, sie zu hören.