Kolumne

DevOps Stories: Keine Haustiere in der IT!

Konstantin Diener

Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen berichtet die Kolumne DevOps Stories. Heute belauschen wir das MusicStore-Team beim morgendlichen Stand-up.

DevOps Stories: Keine Haustiere in der IT!

Lukas: „Guten Morgen, Martin. Ah, du hast schon die Spülmaschine ausgeräumt. Lieb von dir.“
Martin: „Ja, ich habe die Tassen vorsichtshalber mal hier auf dem Tablett abgestellt. Sie sind noch superheiß.“
Lukas: „Ok, dann mache ich mir erst mal ein Müsli.“

Lukas sucht die Zutaten für sein morgendliches Müsli zusammen und hat schon vergessen, dass Martin das Tablett mit den Tassen hinter ihm abgestellt hat. Er unterhält sich mit anderen Kollegen, die in die Kaffeeküche kommen. Dann möchte er einem der Kollegen Platz machen und schubst dabei das Tablett um. Die Tassen zerschellen scheppernd auf dem Küchenboden.

Lukas: „Oh nein, jetzt habe ich alle Tassen zerschmissen.“
Martin: „Das waren doch im Wesentlichen die ganzen Standardtassen aus dem Möbelhaus. Das ist zwar ärgerlich, aber die können wir doch schnell wieder nachbestellen.“
Lukas: „Leider war auch meine Tasse aus dem Urlaub dabei.“
Martin: „… die du immer benutzt?“
Lukas: „Ja, die habe ich schon in meiner alten Firma gehabt. Sie ist handgetöpfert – mit dem Namen des Urlaubsorts und meinem Namen drauf. Die bekomme ich so schnell nicht wieder. Sehr ärgerlich.“
Martin: „Zusammenkleben hilft auch nicht, oder?“
Lukas: „Wohl kaum.“

Die beiden gehen zurück ins Büro des MusicStore-Teams. Christian sitzt vor seinem Rechner und scheint hektisch an einem Problem zu arbeiten.

Martin: „Hey Christian, Lukas ist heute der Elefant im Porzellanladen. Er hat eben ein ganzes Tablett mit Tassen zerdeppert.“
Christian: „Stör mich jetzt nicht. Ich muss hier was fixen.“
Lukas: „Was ist kaputt?“
Christian: „Unsere Build-Umgebung ‚snoopy‘ hat’s zerlegt. Ich versuche gerade, sie wieder zum Laufen zu bringen. Wir können im Moment keinerlei Softwareupdates ausliefern – auch keine Bugfixes.“
Lukas: „Haben wir dafür kein Infrastrukturtemplate?!“
Christian: „Kein aktuelles. Außerdem sind die Pipelines nur auf der Umgebung gespeichert.“
Martin: „Noch ein Einzelstück …“

Abb. 1: Lukas hat aus Versehen seine Lieblingstasse heruntergeworfen

Einzelstücke sind in der IT sehr gefährlich

Der Tag beginnt nicht gut für Lukas. Zuerst geht durch eine Unachtsamkeit seine Lieblingstasse zu Bruch. Vermutlich bekommt er auch erst einmal keinen Kaffee, weil auch alle anderen Tassen in der Kaffeeküche in Scherben liegen. Als wäre das noch nicht genug, eröffnet Christian Martin und ihm, dass ihre Build-Umgebung nicht mehr funktioniert.

Martin fällt auf, dass es zwischen den beiden Vorfällen des Morgens eine Parallele gibt: Es handelt sich beide Male um Einzelstücke. Wenn Lukas nur die Standardtassen aus dem Möbelhaus in Scherben verwandelt hätte, wäre er bestimmt nicht (so) traurig. Nach wenigen Tagen ist der Schrank in der Kaffeeküche wieder gefüllt mit einer ausreichenden Anzahl solcher Tassen, die den primären Zweck haben, (heiße) Flüssigkeiten hineinzufüllen und daraus zu trinken. An Lukas’ Tasse hängen Erinnerungen – an den Urlaub, aus dem er sie mitgebracht hat und sicher auch an verschiedene Situationen im Büro, bei denen „seine Tasse“ dabei war. Er hat mit Sicherheit kurz darüber nachgedacht, sie zu kleben – wie Martin es vorschlägt. Dann hätte er sie weiterhin als Träger von Erinnerungen, zum Kaffeetrinken würde sie sich allerdings nicht mehr eignen.

Als die beiden in das Büro des MusicStore-Teams kommen, ist Christian gerade dabei, ihren Build-Server zu „kleben“. Auch dabei handelt es sich um ein Einzelstück, das kaputtgegangen ist. Das Team hat irgendwann in der Vergangenheit eine (Cloud-)Umgebung gestartet, einen Build-Server wie Jenkins manuell darauf installiert und danach von Hand nach und nach seine Build-Pipelines konfiguriert. Dieses Einzelstück hat im Gegensatz zu Lukas’ Tasse mehr als nur ideellen Wert für den Softwareentwicklungsprozess. Solange die Umgebung nicht mehr funktioniert, kann das Team keinerlei Änderungen in Produktion bringen.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

Randy Bias hat 2016 in einem Blogpost beschrieben, dass die IT-Infrastrukturwelt vor dem Aufkommen von Cloud-Diensten weitgehend durch Einzelstücke geprägt war. In Anlehnung an eine Präsentation von Bill Baker aus dem Jahr 2012 bezeichnet er diese Einzelstücke als Haustiere (Pets). Alle Server haben eindeutige Namen, unter denen sie uns bereits vertraut geworden sind. Der Build-Server des MusicStore-Teams heißt offensichtlich „snoopy“. Er ist von Hand „großgezogen“ worden und es gibt keinen sinnvollen Ersatz. Der Server darf nie ausfallen. Wenn er es doch einmal tut, kümmert sich ein Mensch persönlich um ihn und versucht, ihn wieder gesund zu pflegen (Kasten: „Pets“). Bill Baker zielt in seinem Vortrag darauf ab, dass Skalierung in diesem Kontext nur bedeuten kann, diesen einen Server immer größer und größer zu machen (scale-up).

Pets
Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and „hand fed“. Examples include mainframes, solitary servers, HA load balancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on.

Das Gegenteil zu Haustieren ist Nutzvieh (Cattle). Die einzelnen Tiere haben keine Namen mehr, sondern sind durchnummeriert. Kein Halter einer Nutzviehherde wendet z. B. auch nur ansatzweise einen ähnlichen Aufwand bei einem kranken Tier auf, wie es Herrchen oder Frauchen bei seinem Haustier tut. Auf die IT übertragen bedeutet das, kurzlebigere Infrastrukturkomponenten zu haben, die beliebig gestartet oder gestoppt werden können, ohne dass dies das Gesamtsystem beeinträchtigen würde. Sie sind zu Clustern zusammengefasst, und wenn einer der Clusterknoten ausfällt oder nicht mehr ordnungsgemäß funktioniert, greift kein menschlicher Operator ein. Der Knoten wird automatisiert gestoppt und durch einen voll funktionsfähigen ersetzt, der ebenfalls vollständig automatisiert provisioniert, bestückt und konfiguriert wird (Kasten: „Cattle“).

Cattle
Arrays of more than two servers that are built using automated tools and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of „routing around failures“ by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master.

Abb. 2: Cattle vs. Pet in Bezug auf die Kaffeetasse

Unabhängig davon, wie man persönlich zur modernen Massentierhaltung steht, ist das Konzept von Cattle in der IT sehr sinnvoll. Einzelstücke sind gefährliche Engpässe. Ausfälle führen – wie im MusicStore-Team – mindestens zu sehr viel manuellem Aufwand und negativen Folgen fürs Geschäft.

Auch in der Cloud sind wir vor Einzelstücken nicht gefeit

Cloud-Technologien haben dazu geführt, dass es mittlerweile sehr viel einfacher ist, IT-Infrastruktur nach dem Cattle- und nicht nach dem Pet-Prinzip aufzubauen. Das bedeutet allerdings nicht, dass nicht immer wieder Haustiere auch in der Cloud entstehen. Die Build-Umgebung des MusicStore-Teams liegt auch in der Cloud. Trotzdem wurde sie von Hand gestartet, bestückt und konfiguriert.

In der Vergangenheit hatte das MusicStore-Team bereits Probleme mit von Hand konfigurierter Infrastruktur. Daraufhin hat es für ihr Produkt alle Infrastrukturkomponenten per Infrastructure as Code beschrieben und kann auf Knopfdruck fertig konfigurierte Umgebungen in der Cloud provisionieren.

Selbst in Teams wie dem MusicStore-Team, die Softwareprodukte für die Cloud bauen, sind zentrale Komponenten (im Softwareentwicklungsprozess) historisch bedingt häufig Haustiere. Dabei kann es sich um den Build-Server, den Nexus-Server oder Ähnliches handeln. Einzelstücke führen hier zu den gleichen Problemen wie bei Infrastrukturkomponenten für das eigentliche Produkt.

Christian hat es nach vielen Stunden geschafft, die Pipeline-Definitionen aus der Build-Umgebung zu exportieren. Seitdem gibt es auch für diese Umgebung eine Infrastructure-as-Code-Beschreibung, die Pipeline-Definitionen liegen im Versionierungssystem, und eine neue Umgebung könnte problemlos auf Knopfdruck erzeugt werden. Den prägnanten Namen für die Umgebung hat das Team in diesem Zusammenhang aufgegeben.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: