Dev, Ops, Agile & DevOps in a nutshell.

„Darf's ein bisschen mehr sein?“

Eine ehrliche Betrachtung. Von gestern, der Gegenwart und der Kultur, die hinter Dev Ops steckt.

„Darf's ein bisschen mehr sein?“ Für gewöhnlich kennt man diesen Satz eher aus der Metzgerei und nicht aus der Softwareentwicklung. Allerdings war es auch die erste Reaktion meiner Teamkollegen, als wir, neben einem komplett neuen Architektur-Blueprint, nun auch noch die Verantwortung für unsere Deployments übertragen bekommen haben. Ob diese Frage seine Berechtigung hat? Um zu verstehen, was ich meine, ist es hilfreich, sich die Situation von "Gestern" und von "Heute" einmal anzuschauen und zu vergleichen, was sich verändert hat.

Gestern

In der Regel war es doch so, dass wir Softwareentwickler (SE) von den Anforderungsmanagern (AM), eigene Abteilung, die Anforderungen bekommen haben, die Sachen dann implementierten und danach "über den Zaun" weiter geworfen haben. Der Betrieb (OPS), eigene Abteilung, hat das Zeug irgendwie, irgendwo deployt und uns eine Datenbank hingestellt.

Dann hat sich die Qualitätssicherung (QA), eigene Abteilung, drüber hergemacht. Die QA hat Fehler gemeldet, die wir dann behoben haben und anschließend gab's 'nen Patch. Ich kann mich noch dunkel erinnern, wie ich das ein oder andere Mal so einen Change-Request gestellt habe, der dann über Wochen hinweg von Abteilung zu Abteilung geschoben wurde. Irgendwann dann mal, eine gefühlte Ewigkeit später, landete die Software schlussendlich in Produktion. Wunderbar. Ich schätze, ich bin nicht der Einzige, der solche Erfahrungen machen durfte….

Damit man dieser Hürde so lange wie möglich aus dem Weg gehen konnte, gab es für gewöhnlich längere Projekte, in denen mehrere Features entwickelt wurden, die dann gebündelt, auch gerne mit den Anpassungen mehrerer Teams zusammen, als Release veröffentlicht wurden. Je nach Projekttyp konnte das auch schon mal ne gewisse Zeit in Anspruch nehmen. Projekte in halbjährlicher Dimension waren vermutlich keine Seltenheit. Zumal es auch IT-Abteilungen gab, in denen man die Releases vorher ankündigen musste, damit man überhaupt ein Timeslot für die Auslieferung bekommen hat.

Zu jener Zeit war es die Aufgabe des entwickelnden Fachpersonals Fachlichkeiten zu implementieren.
Der Code konnte in Java o.ä. geschrieben sein, beinhaltete die Fachlogik und ein paar technische Raffinessen. Darunter Persistenz, JEE, JSF etc. Dann wurde noch ein wenig konfiguriert, bei guter Laune Unit-getestet und das Ganze dann, wie bereits erwähnt, über'n Zaun geschmissen.

Doch wie sieht es heute aus? Mein Gefühl sagte mir: "Moment mal, dass ist doch heutzutage nicht mehr so... Ich mach doch mittlerweile viel mehr als nur das".

Willkommen in der Gegenwart

Im Vergleich zu damals wird heutzutage ein agiles Vorgehen bevorzugt. Einige kluge Leute haben nämlich herausgefunden, dass man so schneller auf sich wechselnde Anforderungen reagieren kann. So hat man jetzt AM, SE, QA und OPS in einem Boot und dadurch stark verkürzte Durchlaufzeiten. Natürlich hört das jetzt auch jeder auf den Management-Meetups und Konferenzen und möchte auch schneller werden. Weil, klingt ja erst mal super.

Ist es auch, denn es geht hier nämlich in erster Linie darum, die Kultur eines Unternehmens auf das 21. Jahrhundert umzustellen. Konkret von: "Haben wir immer so gemacht", hin zu: "Haben wir die letzten Wochen so gemacht. War nicht so gut / war super ". In einer Zeit, in der das gesellschaftliche Leben und der Markt durch die exponentiell, wachsenden Innovationen und Prozesse der Computertechnik vorangetrieben werden, ist das auch nötig. Vor allem dann, wenn man auch in Zukunft noch mitspielen möchte.

Dafür muss es allerdings möglich sein, dass Teams unabhängiger und häufiger Software ausliefern können, also schneller reagieren können. Im alten System undenkbar, vor allem im Hinblick darauf, dass in den letzten Jahren exorbitant viele Micro-Services entstanden sind. Um diese auch häufig ausliefern zu können, braucht man den Code permanent unter automatisierter Testabdeckung, optimalerweise im gesamt-integrierten Zustand (Continuous Integration) und muss in der Lage sein, über technische Apis automatisiert hochzustufen (Continuous Deployment). Denn seien wir mal ehrlich - Manuell funktioniert das Deployment bei dutzenden Micro-Services einfach nicht mehr. Zumindest nicht effizient.

Damit die Umstellung und der tägliche Arbeits-Alltag mit den neuen Konzepten reibungslos funktioniert, müssen vor allem die Kommunikationswege verkürzt und technische Lösungen dafür zur Verfügung gestellt werden. Das macht man am einfachsten, in dem man die erforderliche Infrastruktur zur Verfügung stellt und alle beteiligten Schaffenden in fachlich spezialisierten Teams organisiert. Das sind dann cross-funktionale Teams, welche in der Regel aus 4-10 Personen bestehen und für das Konzeptionieren, Erstellen und Betreiben der Software verantwortlich sind. Die klassischen Ops agieren in diesem Umfeld dann nur noch als Dienstleister für die Bereitstellung der benötigten Ressourcen und nicht mehr als Babysitter für meine Anwendung in Produktion. Ob das Ganze eine private Cloud oder die AWS ist, ist hierfür fast schon irrelevant. Technische Lösungen gibt es am Markt zuhauf. Jetzt muss man festhalten, dass die Opsler im Idealfall tatsächlich mit in den Teams sitzen. Meiner Erfahrung nach, können die Leute von Amazon und Co, das aber leider nicht leisten und in vielen Unternehmen, die on-premise hosten, ist die benötigte Transformation vielleicht noch nicht überall in Gänze vollzogen. Das führt in der Realität schonmal dazu, dass die Entwicklergemeinde diese Tätigkeiten übernimmt.

Deshalb sieht es heute wie folgt aus:

Hat man seine Backend- und Frontend-Anwendung geschrieben und konfiguriert, wirft man sie zu sich selbst über den Zaun, denn nun muss man sich Gedanken machen, wie man sein Zeug auch ans Laufen bekommt. Aktuell ein De-facto-Standard ist Docker. Hier definiert man auf Betriebssystemebene, was der Computer eigentlich ausführen soll.
Als nächstes müssen wir definieren, wann unser eben geschriebener Docker-Container wo läuft, wen er ansprechen kann, wer ihn ansprechen kann, wie viel CPU und RAM er braucht, wie oft er instanziiert wird etc. Dies geschieht zum Beispiel mittels Kubernetes. Hat man nun alles richtig zusammen gepuzzelt, geht es im folgenden Schritt darum, eine Build-Pipeline aufzusetzen, in der unser Code a) getestet, b) verpackt und dann c) ausgerollt wird. Dies geschieht im Regelfall mit Cloudinfrastruktur, wie zum Beispiel Kubernetes.
Das Wie und Wo ist also geklärt, stellt sich einem nun natürlich die Frage: "Und jetzt? Wie können wir denn unsere Software auswertbar machen? Wie können wir denn jetzt den korrekten Betrieb gewährleisten und Rückschlüsse ziehen?“
Ganz einfach: Metriken einbauen, auf Produktion wieder einsammeln und in ein Dashboard überführen. Natürlich braucht man bei zig Micro-Services auch wieder Tools, die das leisten können. Damit wir zum Beispiel Logfiles und Meldungen unserer Container einsammeln und wieder auswerten können, greifen wir auf den sogenannten ELK Stack zurück.
All die neuen Tools sind "am Ende des Tages" dafür da, uns graue Haare durch Abstimmungsmeetings, Missverständnisse, Unklarheiten zu ersparen und das Unternehmen damit effizienter aufzustellen als bisher. Chapeau. Das ist doch eigentlich gar nicht so schlecht, oder? Für uns Entwickler stellt sich an der Stelle allerdings die Frage: Spezialist oder Generalist? Wenn Spezi, dann für was?

DevOps

Ist das Ganze dieses DevOps? Nein. Das Schreiben und Konfigurieren der neuen Technik sind Teilaufgabenbereiche von Dev und Ops.
DevOps selbst ist eine Kultur, eine Philosophie, die uns das agile Leben vereinfachen soll.

Sie zeichnet sich durch 4 primäre Leitmotive aus. Automation, Iteration, Feedback und Verbesserung. Das Verbessern der Zusammenarbeit zwischen Dev und Ops, das ist DevOps. Alle Puzzleteilchen in seinem Stack miteinander zu verbinden, darüber zu sprechen und Hindernisse aus dem Weg zu räumen, das ist DevOps.
Die vorgestellten Tools und Methoden, wie CI/CD, Docker, Kubernetes und der ELK-Stack, sollen uns dabei helfen, den Zielzustand, gemäß dieser Leitmotive, zu erreichen. Sie sind, sozusagen, ein Resultat von DevOps und eben daraus entstehen nun neue Stacks mit neuen Aufgaben und Herausforderungen. But don‘t be scared. Das ist nichts, wovor man Angst haben müsste!

Fassen wir nochmal kurz zusammen:

tl;dr

Veränderung und Agilität sind wichtige Aspekte bei der Aufstellung eines Unternehmens für das 21. Jahrhundert. CI/CD wird immer wichtiger und die DevOps-Kultur gewinnt an Relevanz. Mit ihr geht die Betriebsverantwortung immer mehr in Richtung Feature-Team über. Dafür sind viele neue Grundlagen und Tools notwendig, wodurch sich der Entwicklerfokus langsam, aber sicher, verlagert.

Was uns schlussendlich zu der großen Frage bringt: "Darf‘s also ein bisschen mehr sein?"
Von mir aus sehr gern, auch wenn es bedeutet, dass es viel Neues zu erlernen gibt! Aber das macht ja auch den Reiz an der Software-Branche aus. Das Leben selbst ist ja im Grunde auch ein kontinuierlichen Wandel. Und ganz unter uns: Ich vermute, wir kommen auf lange Sicht eh nicht drum herum.

Jetzt teilen:

Kommentare

Einen Kommentar schreiben

Was ist die Summe aus 5 und 5?

Wir verarbeiten Ihre personenbezogenen Daten, soweit es für die Bereitstellung des Kommentars sowie zur Sicherstellung der Integrität unserer informationstechnischen Systeme erforderlich ist. Sie sind zur Bereitstellung dieser Daten nicht verpflichtet, eine Nutzung der Kommentarfunktion ist ohne die Bereitstellung jedoch nicht möglich. Weitere Hinweise zum Datenschutz finden Sie in der Datenschutzerklärung.