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?
