Die Kommodifizierung des Betriebs

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

In früheren Zeiten hatten Autos ein Schaltgetriebe. Manche nannten es wegen des Schalthebels, mit dem man die Gänge wechselte, auch „Knüppelschaltung“. Damals war ein Automatikgetriebe etwas Besonderes, das man häufig extra bestellen musste. Seinen Namen verdankt es der Tatsache, dass das Auto die Gänge automatisch wechselt. Und das ist, ehrlich gesagt, ziemlich angenehm. Schließlich muss man beim manuellen Schalten eine ganze Reihe von Faktoren im Blick behalten.

Heutzutage sind Automatikgetriebe Standard. Schaltgetriebe sind den meisten ein Rätsel. Ich habe versucht, meinen drei ältesten Kindern das Fahren mit Schaltgetriebe beizubringen. Falls Sie das auch vorhaben, kann ich nur davon abraten. Zumindest, wenn Ihnen an einem funktionierenden Getriebe gelegen ist.

Ich erwähne diesen Wandel bei Erwartungen und Standards als Auftakt zu einer Diskussion über den IT-Betrieb. Dabei geht es vor allem um die Infrastruktur für Netzwerk- und Anwendungsdienste, doch dies gilt auch über diese Bereiche hinaus.

Betriebliche Erwartungen

Der Wandel geht zwar in Richtung Automatisierung, doch zugleich verändern sich auch die Erwartungen an die Kenntnisse, die für den Betrieb von Infrastruktur erforderlich sind.

Um noch einmal auf meine Getriebeanalogie zurückzukommen: Wenn Sie ein Auto mit Schaltgetriebe fahren, müssen Sie viele Variablen im Blick behalten. Sie müssen Kupplung und Gaspedal aufeinander abstimmen. Sie müssen auf den Motor hören und erkennen, wann Sie schalten müssen. Außerdem müssen Sie wissen, welcher Gang eingelegt ist, in welchen Gang Sie schalten möchten und wie Sie den „Schalthebel“ bewegen müssen, um dorthin zu gelangen.

Dies entspricht den Kenntnissen, die Sie benötigen, um die Infrastruktur für Netzwerk- und Anwendungsdienste manuell bereitzustellen. Sie müssen genau wissen, wie das Netzwerk funktioniert, damit der Datenverkehr zuverlässig von einem Ort zum anderen gelangt.

Mit der Einführung der Cloud begannen sich die Erwartungen von diesem „Standard“ wegzuentwickeln. Zwar müssen Sie nach wie vor einige grundlegende Netzwerkkonzepte verstehen, aber nicht unbedingt wissen, wie sie funktionieren. Mit der Einführung von Containern haben sich die Erwartungen noch weiter nach rechts verschoben – sodass man sich kaum oder gar keine Gedanken mehr über IP-Adressen machen muss.

Dadurch verändern sich die Erwartungen an den Betrieb. Wir bewegen uns von einer Wirtschaft mit Expertenbetrieb hin zu einer Wirtschaft mit standardisiertem Betrieb. Heute wird erwartet, dass die betrieblichen Aspekte der Bereitstellung von Netzwerk- und Anwendungsdienstinfrastrukturen einem breiteren Spektrum von Rollen innerhalb des Unternehmens zugänglich sind. Um dieses Ziel zu erreichen, ist eine Vereinfachung erforderlich.

Genauer gesagt: betriebliche Vereinfachung. Es reicht nicht aus, Netzwerk- und Anwendungsdienste über Self-Service-Optionen bereitzustellen; sie müssen auch für diejenigen nutzbar sein, die sie nun einmal verwenden werden. Es muss noch einfacher werden, als es heute ist.

Das kann bedeuten, zugunsten der Bedienbarkeit Abstriche bei der Konfigurierbarkeit zu machen.

Konfigurierbarkeit versus Bedienbarkeit

Wie bei Cloud und Containern erstrecken sich die Abstraktionen, die über die Infrastruktur für Netzwerk- und Anwendungsdienste gelegt werden, auch auf die Nutzung dieser Abstraktionen. Damit meine ich die Fachsprache. Die Terminologie. Das Datenmodell. Die tatsächliche Konfiguration.

Für die Nichtprogrammierer unter den Lesern: Damit meine ich, dass jedes Konstrukt über eine Reihe zugehöriger Attribute verfügt, die zusammen das „Objekt“ bilden. Ein virtuelles Serverobjekt hat eine IP-Adresse, einen Pool von Anwendungen, Ereignisse, einen Namen und eine ganze Reihe weiterer Eigenschaften. Einige dieser Eigenschaften sind selbst Objekte oder Listen von Objekten. Das Durchlaufen dieser Konstrukte kann komplex sein. Denn Konfigurierbarkeit ist bei der Feinabstimmung der Infrastruktur unerlässlich. Man muss sehr spezifische Eigenschaften anpassen können – etwa den Nagle-Algorithmus ein- oder ausschalten oder die TCP-Fenstergröße verändern –, um die Leistung oder Kapazität zu optimieren.

In einem standardisierten Betriebsmodell – und genau darauf steuern wir zu – ist die Betriebsfähigkeit wichtiger als die Konfigurierbarkeit. Weniger Optionen, schnellere Betriebsbereitschaft.

Das bedeutet jedoch nicht, dass Optionen einfach entfernt werden sollten. Allein die Möglichkeit zur Anpassung von Optionen zu beseitigen, erfüllt lediglich die grundlegenden Anforderungen an die Bedienbarkeit; die Erwartungen an eine vereinfachte Betriebsführung werden damit nicht erfüllt. Das Objektmodell muss weiterhin verstanden werden. Daher muss das Modell abstrahiert und vereinfacht werden. Beispielsweise könnte ein virtueller Server auf eine IP-Adresse, einen Namen und eine Liste von Anwendungsinstanzen reduziert werden.

Kommodifizierung erfordert Standardisierung

Dies ist ein bedeutendes Unterfangen, da es kein einheitliches Modell für den Betrieb der Infrastruktur von Anwendungsdiensten gibt. Die Darstellung virtueller Server, der Steuerung eingehender Verbindungen und der Sicherheitsrichtlinien unterscheidet sich von Produkt zu Produkt und von Dienst zu Dienst.

Ops – ob auf Entwicklungs- oder IT-Seite – muss im Grunde eine Vielzahl von Modellen verstehen, um die im Durchschnitt vierzehn Anwendungsdienste bereitzustellen und zu betreiben, die zur Auslieferung und Absicherung von Anwendungen eingesetzt werden. Die Unterschiede sind groß, was in der Vergangenheit dazu geführt hat, dass unzählige Zertifizierungen erforderlich waren, um die für die Verwaltung dieser Dienste nötige Fachkompetenz nachzuweisen.

Der andere operative Wandel führt weg von diesem Ansatz. Erwartet werden Einfachheit, Benutzerfreundlichkeit und Einheitlichkeit über verschiedene Angebote hinweg, um die durch gerätespezifische Betriebsmodelle entstandenen technischen Altlasten zu reduzieren. Es wird eine Standardisierung erwartet – nicht von Protokollen und Netzwerkverhalten, denn diese gibt es im Bereich der Netzwerkinfrastruktur bereits, sondern davon, wie wir diese Protokolle und Netzwerkverhaltensweisen darstellen.

Dies zeigt sich auch in Umfragen zur Containerisierung, in denen fast jeder vierte Befragte (24 %) die erforderlichen Kompetenzen als wesentliches Hindernis für die Einführung bezeichnete, während 33 % sie als mäßiges Hindernis einstuften. Der Mangel an Fachkräften und der Wunsch nach mehr Geschwindigkeit treiben die Infrastruktur – zu der angesichts ihrer heutigen Verbreitung in Produktionsumgebungen zweifellos auch Container und Systeme zur Container-Orchestrierung gehören – in Richtung standardisierter Betriebsabläufe.

Dieser Wunsch und Bedarf zeigt sich in der organischen Einführung von Kubernetes-Ressourcendateien, mit denen versucht wird, die genannten Infrastrukturdienste zu beschreiben. Diese Ressourcen zwingen alle Betriebsteams dazu, ein gemeinsames (standardisiertes) Datenmodell (Format) zur Beschreibung der Bereitstellung und Konfiguration eines bestimmten Dienstes zu verwenden. Da der IT-Betrieb heute der wichtigste Treiber für die Einführung von Containern (35 %) in Unternehmen ist (laut Diamantis Umfrage zur Container-Einführung 2019) – und damit fast doppelt so einflussreich wie Entwickler (16 %) und viermal so einflussreich wie integrierte DevOps-Teams (9 %) –, ist es wichtig, diesen Wandel zu erkennen und sorgfältig zu prüfen, wie sich neue Infrastruktur in eine standardisierte Betriebsumgebung einfügt (oder auch nicht).

Mit oder ohne offizielle Bemühungen (von Arbeitsgruppen oder Stiftungen) wird die Kommodifizierung einen De-facto-Standard für den IT-Betrieb hervorbringen. Und dieser De-facto-Standard wird den Schwerpunkt auf Betreibbarkeit statt auf Konfigurierbarkeit legen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie