Seite 2: Das Business gehört dazu

Inhaltsverzeichnis

Im Gegensatz zu horizontalen Aspekten wie Sicherheit oder Design, Test oder Architektur ist das Business sehr wohl ein vertikaler Aspekt, der viel zu oft unter den Tisch fällt. Streng genommen müsste stets von BizDevOps die Rede sein.

Business deckt alle relevanten Aspekte ab, die sich mit dem Sinn und Zweck eines Softwaresystems sowie dessen Anforderungsanalyse und Planung beschäftigen. Das Business klärt, was zu entwickeln ist, Development klärt, wie es zu entwickeln ist, Operations klärt, wo es betrieben wird.

Vergesst die DevOps Engineers

Jedem der bereits erwähnten Schlagworte lässt sich in der Regel auch eine fachliche Spezialisierung oder Rolle zuordnen. DevOps Engineers stehen hoch im Kurs. Was genau ein DevOps Engineer ist, welche Aufgaben zu dieser Fachspezialisierung gehören und welches Wissen dafür notwendig ist, lässt sich jedoch kaum zuverlässig klären. Als echter DevOps Engineer darf sich streng genommen nur bezeichnen, wer von der Softwareentwicklung bis zu kleinsten Aspekten des Betriebs alles beherrscht.

Anstelle solcher Einzelkämpfer gelten in der DevOps-Praxis crossfunktionale Teams als Königsweg. Das bedeutet, dass in einem DevOps-Team Personen mit sowohl differenzierenden als auch sich überschneidenden Fähigkeiten gemeinsam arbeiten. Dazu gehören beispielsweise Entwickler, die UI-Design verstehen, Ops-Verantwortliche, die Software entwickeln können, Datenbank-Administratoren, die UI-Design und Testing beherrschen und so weiter. Die Kombinationen sind beliebig; Hauptsache, alle im Team benötigten Kenntnisse sind vorhanden, idealerweise mehrfach auf viele Köpfe verteilt. Fällt eine Person aus, können andere die Aufgaben übernehmen. Das Team bleibt stabil und arbeitsfähig.

Die Stabilität geht jedoch verloren, wenn eine einzelne Person die komplette Rolle als DevOps Engineer ausfüllen muss. Häufig sollen sich diese Einzelkämpfer dann um alle DevOps-Aspekte kümmern, die Werkzeuge und Prozesse etablieren und pflegen, den Betrieb organisieren und garantieren. Fällt die Person aus, ist das gesamte Team aufgeschmissen. Die vereinte Verantwortung lastet dann auf einer einzelnen Person – das widerspricht dem wichtigen DevOps-Grundprinzip.

Für alles gibt’s ein Werkzeug

Für jede Aufgabe gibt es nicht nur ein Werkzeug, eine Methode oder eine Technologie, sondern es existieren viele verschiedene, die immer unterschiedlich gut geeignet sind. Um Licht in dieses Dickicht zu bringen, greifen viele DevOps-Teams auf etablierte Muster und Blueprints anderer Teams zurück – in der Hoffnung, sich den Aufbau eines individuellen Werkzeugkastens ersparen zu können. Das ist jedoch eine Fehleinschätzung, die allzu oft in Missverständnissen und Dogmatismus mündet, wie Beispiele namhafter Unternehmen zeigen.

Das Unternehmen Spotify etwa gilt als einer der Vorreiter in Sachen Agilität. Der Streaming-Dienst hat eine Auswahl an Werkzeugen, Methoden und Technologien sondiert und daraus ein auf das Unternehmen, dessen Produkt sowie den adressierten Markt passgenaues Arbeits-Set zusammengestellt. Spotify hat diesen Ansatz auch sehr offensiv publik gemacht, unter anderem im Rahmen verschiedener Konferenzen, sodass sich schnell die Bezeichnung Spotify-Modell etablierte. Daraufhin fühlten sich viele Unternehmen motiviert, genau dieses Modell exakt so wie Spotify aufzugreifen und anzuwenden. Das Setup ist allerdings auf Spotify maßgeschneidert. Bei dem Streaming-Dienst passt das Spotify-Modell perfekt, bei anderen Unternehmen hingegen nicht.

Jedes DevOps-Team muss sich aus den vorhandenen Werkzeugen, Methoden und Technologien ein eigenes maßgeschneidertes Set zusammenstellen. Einflussfaktoren für die Auswahl sind Erfahrung und Vorlieben, Organisation und Zielsetzung. Dass beispielsweise ein ganzer Industriezweig ein bestimmtes Werkzeug favorisiert, heißt noch lange nicht, dass es auch für jedes DevOps-Team geeignet ist.

Die Wahrheit liegt im Code

Kaum finden sich Fachanalysten, Developer, Entwicklerinnen und Betriebler im selben Team wieder, starten die Diskussionen über die Vorgehensweisen. In der Softwareentwicklung haben sich über die Jahrzehnte hinweg viele als sinnvoll geltende Regeln, Erfahrungen und Praktiken etabliert. Diese Regeln eignen sich auch im DevOps-Kontext. Sie bilden die Grundlage für automatisierte Arbeitsabläufe und rasche Rückmeldungen.

Für alle Developer gilt dabei, dass sie lesbaren Code schreiben müssen. Dieser Code muss für alle Beteiligten einsehbar und verständlich sein. Das setzt einen professionellen, einheitlichen Programmierstil und selbstverständlich Tests voraus; unverständlicher Code ist in jedem Fall zu überarbeiten. Der fachliche Aspekt, was zu entwickeln ist, muss im Code nicht nur verankert sein, sondern sich auch unmissverständlich daraus ablesen lassen. Dazu kommen konsequenterweise Versionskontrollsysteme sowie Programme zur Fehlerverfolgung zum Einsatz. Sämtliche DevOps-Teammitglieder müssen mit diesen Werkzeugen umgehen können und Zugang zu ihnen haben.

Zu guter Letzt sind noch einige wichtige Weisheiten und Prinzipien zu beachten, wie etwa KISS für "keep it simple, stupid", YAGNI für "you aren’t gonna need it" und DRY für "don’t repeat yourself". Denn je mehr unterschiedliche Personen zusammenarbeiten, desto mehr Ideen und Wünschen fließen ein, desto mehr Interpretationsvielfalt entsteht und desto wahrscheinlicher ist es, dass ein Team in die falsche Richtung abbiegt.

Kontinuität etablieren

Wer mit seinen Produkten den gewachsenen Marktanforderungen gerecht werden will, muss regelmäßig und in kurzen Zeitabständen neue oder verbesserte Softwaresysteme ausliefern. Sei es, neue Funktionen nachzulegen oder wichtige Sicherheitskorrekturen bereitzustellen, um am Markt relevant zu bleiben. Das gelingt durch kontinuierlich ablaufende Arbeitsschritte, erfordert allerdings auch ein hohes Maß an Erfahrung.

Kontinuität zu gewährleisten, ist ab dem Punkt entscheidend, an dem der fertige Code in das Versionskontrollsystem übertragen ist. Dazu bedarf es einer maßgeschneiderten und optimal konfigurierten Pipeline, die hinterlegte Tests ausführt, die Qualität des Codes prüft und Codeänderungen in die Basis sowie Artefakte in andere Systeme integriert. Über die Pipeline läuft zudem das Paketieren für unterschiedliche Plattformen, das Verteilen der Pakete über die entsprechenden Kanäle sowie gegebenenfalls das Installieren auf Zielsystemen.

Welche Bereiche die Pipeline im Detail abdecken soll, muss das DevOps-Team individuell entscheiden: Von Continuous Testing bis Continuous Delivery ist alles möglich. Die Verteilfrequenz einer Anwendung steigt dadurch erheblich, lässt sich mit entsprechenden Maßnahmen aber gezielt justieren.

Automatisierung leben

Kontinuität bedeutet schlicht, bestimmte Aufgaben regelmäßig abzuarbeiten, sobald ein bestimmtes Ereignis eintritt. Automatisierung bedeutet hingegen, manuelle, aufwendige, wiederkehrende Arbeitsschritte ohne menschlichen Eingriff durchzuführen. Kontinuität kann also manuell sein, Automatisierung muss nicht kontinuierlich erfolgen.

Auch Automatisierung ist ein Aspekt, der die Ausliefergeschwindigkeit erheblich reduzieren kann. Gleichzeitig erfordert sie eine Investition in die erstmalige Automatisierung der Aufgaben und danach in deren Pflege. Zudem ist immer wieder ein signifikantes Maß an Erfahrung notwendig, um zu wissen, was sich wie in welcher Situation automatisieren lässt. Und wann es unangebracht wäre.

Im Zuge der Automatisierung ist dann auch deren Überwachung relevant. Denn sobald etwas unbeobachtet abläuft und das DevOps-Team auftretende Probleme nicht rechtzeitig erkennt, droht die Gefahr massiver Ausfälle. Das Höchstmaß an Automatisierung stellt derzeit der GitOps-Ansatz dar, der allerdings auch die Komplexität erhöht.