Unternehmen wenden sich zunehmend an DevOps, um ihre digitalen Transformationen zu unterstützen. Hier ist eine klare Sicht auf das, worauf Sie sich einlassen, wenn Sie es tun. [...]
Am Anfang standen der Code und der Programmierer, der ihn erstellt hat. Die Entwickler waren für alles verantwortlich. Sie gestalteten die Logik und drückten dann die notwendigen Tasten, um sie auf dem Server laufen zu lassen. Das änderte sich mit der Erweiterung der Teams und der Differenzierung der Arbeit, wobei einige Teammitglieder mit dem Code (devs) und andere mit den Maschinen (ops) arbeiten.
Heutzutage, dank der Cloud und dem Aufkommen von Microservices, ist Software zu einer Konstellation von Dutzenden, ja sogar Tausenden von Komponenten geworden, die auf separaten Geräten laufen. Jede ist technisch unabhängig, aber alle diese Geräte müssen zusammenarbeiten. Um sicherzustellen, dass sie dies tun, werden am besten automatisierte Skripte verwendet.
Die Hauptaufgabe des DevOps-Teams besteht darin, die gesamte High-Level-Orchestrierung dieser vielseitigen Apps zu gewährleisten. Sie befassen sich vielleicht nicht mit den tiefsten Winkeln der Softwarearchitektur, aber sie sorgen zumindest dafür, dass ihre Teile reibungslos laufen.
Dennoch bleibt ihre Rolle relativ neu, mit Verantwortlichkeiten, die nicht klar definiert oder zugewiesen sind, und Fähigkeiten, die sich noch entwickeln. Einige DevOps-Profis übergreifen Stellenbeschreibungen, die eine Mischung aus Programmierung und Operationen durchführen, aber viele Teams stellen fest, dass es allein genug ist, dafür zu sorgen, dass alle Server reibungslos laufen. Die Konfiguration erfordert eine besondere Aufmerksamkeit für Details, während das Programmiererteam den Code und damit seine Funktionsweise anpasst.
Da sich immer mehr Unternehmen an DevOps wenden, um ihre digitalen Transformationen zu unterstützen, ist es wichtig, einen klaren Blick zu bekommen. Hier sind ein paar verborgene Wahrheiten und weit verbreitete Missverständnisse über das entstehende Feld von DevOps.
DevOps ist nicht wirklich Programmieren, aber irgendwie doch
Viele Manager denken, dass DevOps nichts mit Programmieren zu tun hat und sie haben Recht. Die Jobs sind unterschiedlich und ein Großteil der chaotischen Arbeit im Umgang mit Bytes und Datenstrukturen ist Programmierern zugeordnet, die in einer anderen abstrakten Welt leben. Strategisch ist es sinnvoll, Programmierer von der Verantwortung zu befreien, alles am Laufen zu halten, da ihre Köpfe tief im Dickicht eines modernen Stacks verloren gehen.
Aber DevOps-Teammitglieder müssen noch Code schreiben. Sie müssen noch abstrakt über versteckte Datenstrukturen nachdenken. Lediglich die Aufrechterhaltung des Betriebs erfordert endlose Befehlszeilenaufrufe, die normalerweise als Shellskripte gesammelt und vereinfacht werden können. Während einige Programmierpuristen High-Level-Arbeiten wie diese nicht als Codierung einstufen, auch wenn sie Funktionsaufrufe, Parameter und Variablen beinhalten, ist die Realität, dass viele dieser Fähigkeiten, die denen von Programmierern entsprechen, dort im Einsatz sind.
Programmierer zu hüten ist Arbeit
Auch wenn DevOps-Profis den Code nicht schreiben, verwalten sie am Ende die Programmierer und das ist oft genauso viel Arbeit. Jeder Entwickler erschafft etwas Neues und Schönes. Ihr Code ist Kunst. Jeder will seinen Container sofort in die Produktion bringen, damit er ihn von der Liste streichen kann. Läuft der Code reibungslos? Sie denken schon. Aber wird das Ganze zusammenbrechen? Sicherstellen, dass die Programmierer die Dinge nicht vermasseln, ist das schwierige Handwerk von DevOps.
DevOps übernimmt langsam die Führung
Als die Software noch monolithisch war, hatten die Programmierer die volle Kontrolle. Jetzt, da Apps typischerweise in Dutzende oder sogar Hunderte von Mikroservices unterteilt sind, ist DevOps dafür verantwortlich, wie gut sie laufen. Ja, es gibt immer noch Architekten und Programmierer, die Entscheidungen über die Art und Weise treffen, wie die Dienste miteinander verbunden sind, aber DevOps-Profis sind dafür verantwortlich, wie sie miteinander verbunden sind, was ein immer wichtigerer Teil des Puzzles ist.
Wir schauen nicht aufs Geld
Die Cloud-Firmen waren klug genug, ihre Maschinen in Pennys pro Stunde zu tarifieren. Wer hat nicht noch etwas Kleingeld übrig? Aber die Cents summieren sich, wenn sich die Anzahl der Cloud-Instanzen nach oben dreht und die Stunden vergehen. Es gibt 720 Stunden in einem 30-Tage-Monat und so werden die Kosten für eine fette Anlage, die nur einen Euro pro Stunde kostet, 8.760 Euro für ein Jahr betragen. Plötzlich erscheint der Kauf einer eigenen Box billiger.
Nachdem sie einige schockierende Rechnungen erhalten haben, gründen einige Teams von DevOps-Auditoren mit der einzigen Aufgabe, in dem Durcheinander von Geräten herumzustochern und nach Möglichkeiten zu suchen, Geld zu sparen. Sie hinterfragen die Entscheidungen ihrer Mitarbeiter und beginnen, „Nein“ zu sagen. Sie zählen jeden Bruchteil eines Cents, weil sie wissen, dass das Budget es erfordert.
Es gibt nur wenige Maßnahmen zur Leistungssteigerung
Die Arbeit beim Management der Cloud wird durch die Tatsache erschwert, dass das DevOps-Team oft nur wenige Möglichkeiten hat, etwas in Gang zu bringen. Sobald die Programmierer den Code übertragen und die Container erstellt haben, ist es der DevOps-Teamjob, sie zum Laufen zu bringen. Wenn sie langsam erscheinen, können sie versuchen, mehr virtuelle CPUs oder mehr RAM hinzuzufügen. Wenn die Dinge dann immer noch zu langsam sind, können sie dem Pod weitere Maschinen hinzufügen, um die Last zu verteilen. Das war’s dann auch schon.
Es ist ein Abrissderby
Eines der tiefgreifendsten Probleme ist, dass die Computer immer wieder über ihre Fehler hinwegtäuschen. Ich habe einmal eine Sammlung von Containern übernommen, die alle paar Stunden abstürzte. Vielleicht war es eine fehlerhafte Datenbankverbindung. Vielleicht war es ein falsch konfigurierter Parameter. Die Antwort mag tief in den Logdateien gelegen haben, aber ich habe es nie herausgefunden. Kubernetes war so freundlich, eine weitere Instanz zu starten, und der Pod segelte weiter, beantwortete Fragen und erledigte seine Arbeit. Es war ein schönes Beispiel für eine ausfallsichere Architektur, auch wenn es im Inneren ein Chaos war.
Manchmal stürzen die Container und Instanzen unter der Oberfläche überall ab. Solange die Benutzer und Kunden ihre Arbeit erledigen können, ist es oft einfacher für alle, in eine andere Richtung zu schauen und den ganzen virtuellen Abriss zu ignorieren.
Datenbanken bestimmen alles
Wir können uns mit dem ganzen selbstgebauten Code beschäftigen und mit AJAX hier oder CSS dort herumfummeln, aber am Ende finden alle Daten in der Datenbank ein Zuhause. Die klassischen Datenbanken bleiben die Sonne, um die der Code kreist. Sie ist die einzige Quelle der Wahrheit. Wenn das Team in der Lage ist, sie am Laufen zu halten und Anfragen zu beantworten, ist das fast der gesamte Job. Benutzer können falsch ausgerichtete DIVs oder seltsame neue Layouts tolerieren, aber keine beschädigten Datenbanken. Ich habe einmal den Code für ein Team überprüft, das die neuesten, großartigsten Node.js-Pakete verwendet und ihren Stack unermüdlich aktualisiert hat, um immer auf dem neuesten Stand zu bleiben. Aber die Datenbank war mehr als 10 Jahre alt. Niemand wollte sich damit auseinandersetzen.
Wir wissen nur so viel darüber, wie der Code uns sagt
Das Niveau der heute verfügbaren Instrumentierung kann erstaunlich sein. Wir können spüren, wie die Daten durch die verschiedenen Programme fließen, wie ein Segler den Wind spürt. Wenn die Lasten der Pods schwinden und fließen, wissen wir, wann die Dinge richtig laufen und wann sie strapaziert werden. Wenn wir für eine E-Commerce-Webanwendung verantwortlich sind, werden wir die Ersten sein, die wissen, wann die Rabatte einsetzen, weil die Last für diesen Bereich der App ansteigt.
Aber die Instrumentierung kann uns nur so viel sagen. Die Zahlen fassen die durchschnittliche Belastung und Reaktionszeit der Komponente zusammen, aber sie können uns nicht sagen, weshalb. Das bleibt den Programmierern überlassen, die wissen, was in den Komponenten vor sich geht. Sie können die Fehler isolieren und Lösungen finden.
Einige Geschäftsleute mögen sich wünschen, dass es allmächtige, allwissende Tech-Mitarbeiter gab, die den gesamten Stapel von unten nach oben verstehen können. Es gibt ein paar Übermenschen da draußen, aber für viele Unternehmen ist der Job zu groß und die Zeilen des Codes zu komplex. Es ist besser, daran zu arbeiten, einen einfachen Weg für DevOps und die Programmierer zu finden, dait sie zusammenzuarbeiten.
Es ist alles ein bisschen geheimnisvoll
Computer können völlig logische Maschinen sein, bei denen sich der Code auf eine vorhersehbare, deterministische Weise entwickelt. Jeder Bug passiert aus einem bestimmten Grund. Wir könnten die Debugger herausholen, durch die Protokolldateien scrollen und den Code untersuchen, aber wer hat die Zeit?
Gerade als es sich anfühlt, als ob 90 Prozent der technischen Supportprobleme durch Power-Cycling des Geräts gelöst werden können, beinhaltet ein Großteil von DevOps, immer das gleiche zu tun. Oh sicher, wir verwenden Wörter wie „Container“ und „Instanzen“ und haben endlose Dashboards, um zu verfolgen, was passiert, aber am Ende ist es oft schneller und einfacher, einfach weiterzumachen und, wie Iris Dement vorgeschlagen hat, das Geheimnis auf sich beruhen zu lassen.
*Peter Wayner ist Mitredakteur bei InfoWorld und Autor von mehr als 16 Büchern zu verschiedenen Themen, darunter Open-Source-Software, autonome Autos, privat genutzte Berechnungen, digitale Transaktionen und Steganographie.
Be the first to comment