9 dunkle Geheimnisse aus der Welt von DevOps

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. [...]

DevOps behält die Softwareentwicklung im Auge und ist damit ein wichtiger Bestandteil der Programmierung. Ihre Aufgaben können dabei schon mal eintönig werden (c) Kristina Flour; modified by IDG / Credit URL: https://unsplash.com/photos/BcjdbyKWquw / C00

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.


Mehr Artikel

News

ISO/IEC 27001 erhöht Informationssicherheit bei 81 Prozent der zertifizierten Unternehmen

Eine Umfrage unter 200 Personen verschiedener Branchen und Unternehmensgrößen in Österreich hat erstmals abgefragt, inwiefern der internationale Standard für Informationssicherheits-Managementsysteme (ISO/IEC 27001) bei der Bewältigung von Security-Problemen in der Praxis unterstützt. Ergebnis: Rund 81 Prozent der zertifizierten Unternehmen gaben an, dass sich durch die ISO/IEC 27001 die Informationssicherheit in ihrem Unternehmen erhöht hat. […]

News

Public Key Infrastructure: Best Practices für einen erfolgreichen Zertifikats-Widerruf

Um die Sicherheit ihrer Public Key Infrastructure (PKI) aufrecht zu erhalten, müssen PKI-Teams, sobald bei einer Zertifizierungsstelle eine Sicherheitslücke entdeckt worden ist, sämtliche betroffenen Zertifikate widerrufen. Ein wichtiger Vorgang, der zwar nicht regelmäßig, aber doch so häufig auftritt, dass es sich lohnt, PKI-Teams einige Best Practices für einen effektiven und effizienten Zertifikatswiderruf an die Hand zu geben. […]

News

UBIT Security-Talk: Cyberkriminalität wächst unaufhaltsam

Jedes Unternehmen, das IT-Systeme nutzt, ist potenziell gefährdet Opfer von Cyberkriminalität zu werden, denn die Bedrohung und die Anzahl der Hackerangriffe in Österreich nimmt stetig zu. Die Experts Group IT-Security der Wirtschaftskammer Salzburg lädt am 11. November 2024 zum „UBIT Security-Talk Cyber Defense“ ein, um Unternehmen in Salzburg zu unterstützen, sich besser gegen diese Bedrohungen zu wappnen. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*