Die Kommerzialisierung von Operationen

Früher waren die Getriebe in Autos manuell. Manche haben sie aufgrund des Mechanismus zum Schalten der Gänge vielleicht als „Schaltknüppel“ bezeichnet. Ein Automatikgetriebe war damals noch etwas Besonderes, das man oft extra bestellen musste. Der Name rührt von der Art und Weise her, wie das Auto automatisch die Gänge für Sie wechselt. Was, um ehrlich zu sein, ganz nett ist. Schließlich müssen beim manuellen Schalten viele Variablen berücksichtigt werden. 

Heute sind Automatikgetriebe der Standard. Die Bedienungsanleitung ist für die meisten ein Rätsel. Ich habe versucht, jedem meiner drei ältesten Kinder das Fahren beizubringen. Wenn Sie darüber nachdenken, rate ich Ihnen von einem solchen Versuch ab. Nicht, wenn Sie ein funktionierendes Getriebe in Ihrem Auto haben möchten. 

Ich erwähne diesen Wandel in den Erwartungen und Standards als Auftakt zu einer Diskussion über den Betrieb. Dies gilt hauptsächlich für die Netzwerk- und Anwendungsdiensteinfrastruktur, aber auch außerhalb dieser Bereiche. 

Betriebliche Erwartungen 

Zwar geht der Trend in Richtung Automatisierung, doch verändert sich auch die Erwartungshaltung hinsichtlich des für den Betrieb der Infrastruktur erforderlichen Wissens. 

Um auf meine Getriebeanalogie zurückzukommen: Wenn Sie ein Fahrzeug mit manueller Schaltung fahren, müssen Sie viele Variablen berücksichtigen. Kupplung und Gas müssen koordiniert werden. Sie müssen auf den Motor hören und erkennen, wann Sie den Gang wechseln müssen. Sie müssen auch wissen, in welchem Gang Sie sind, in welchen Gang Sie schalten und wie Sie den „Steuerknüppel“ bewegen, um dorthin zu gelangen. 

Diese spiegeln die Art von Wissen wider, die Sie zum manuellen Bereitstellen der Netzwerk- und Anwendungsdienstinfrastruktur benötigen. Sie müssen viel über die Funktionsweise des Netzwerks wissen, um sicherzustellen, dass der Datenverkehr von einem Ort zum anderen gelangt. 

Mit der Einführung der Cloud begann eine Abkehr von diesem „Standard“. Sie müssen zwar einige grundlegende Netzwerkkonzepte verstehen, aber nicht unbedingt, wie sie funktionieren. Mit der Einführung von Containern hat sich diese Erwartungshaltung noch weiter nach rechts verschoben – man muss sich kaum oder gar keine Gedanken mehr über IP-Adressen machen. 

Dies führt zu einer Veränderung der betrieblichen Erwartungen. Wir bewegen uns von einer auf Expertenbetrieben basierenden Wirtschaft zu einer auf Warenbetrieben basierenden Wirtschaft. Heutzutage wird erwartet, dass die operativen Aspekte der Bereitstellung einer Netzwerk- und Anwendungsdienstinfrastruktur für ein breiteres Spektrum an Rollen innerhalb der Organisation zugänglich sind. Um dieses Ziel zu erreichen, ist eine Vereinfachung erforderlich. 

Genauer gesagt: betriebliche Vereinfachung. Es genügt nicht, Netzwerk- und Anwendungsdienste über Self-Service-Optionen bereitzustellen; sie müssen auch für diejenigen nutzbar sein, die sie nutzen wollen. Es muss noch einfacher werden, als es jetzt schon ist. 

Das kann bedeuten, dass die Konfigurierbarkeit zugunsten der Bedienbarkeit geopfert wird. 

Konfigurierbarkeit versus Bedienbarkeit 

Wie bei Cloud und Containern erstrecken sich die auf der Netzwerk- und Anwendungsdienstinfrastruktur basierenden Abstraktionen auf die Verwendung dieser Abstraktionen. Damit meine ich die Umgangssprache. Die Terminologie. Das Datenmodell. Die eigentliche Konfiguration . 

Was ich damit für die Leser, die keine Programmierer sind, meine, ist, dass jedem Konstrukt eine Reihe von Attributen zugeordnet sind, die das „Objekt“ bilden. Ein virtuelles Serverobjekt hat eine IP-Adresse, einen Pool von Anwendungen, Ereignissen, einen Namen und eine ganze Reihe anderer Eigenschaften. Einige dieser Eigenschaften sind tatsächlich Objekte – oder Objektlisten. Das Durchqueren dieser Konstrukte kann komplex sein. Denn bei der Feinabstimmung der Infrastruktur ist Konfigurierbarkeit zwingend erforderlich. Sie möchten die Möglichkeit haben, ganz bestimmte Eigenschaften anzupassen (z. B. den Nagle-Algorithmus umzuschalten oder die TCP-Fenstergröße zu verändern), um die Leistung oder Kapazität zu optimieren. 

In einem standardisierten Betriebsmodell - und daraufzusteuern wir - ist die Bedienbarkeit wichtiger als die Konfigurierbarkeit. Weniger Optionen, schnellere Verfügbarkeit. 

Dies bedeutet jedoch nicht, Optionen einfach wegzunehmen. Durch die Beseitigung der Möglichkeit zur Feinabstimmung von Optionen werden lediglich die Grundanforderungen an die Bedienbarkeit erfüllt, nicht aber die Erwartungen an eine vereinfachte Bedienung. Sie müssen das Objektmodell weiterhin verstehen. Was notwendig ist, ist, das Modell in etwas Einfacheres zu abstrahieren. Reduzieren Sie beispielsweise einen virtuellen Server auf eine IP-Adresse, einen Namen und eine Liste von Anwendungsinstanzen. 

Kommerzialisierung erfordert Standardisierung

Dies ist ein erhebliches Unterfangen, da es kein gemeinsames Modell für die Funktionsweise der Anwendungsdienstinfrastruktur gibt. Die Darstellung von virtuellen Servern, Eingangskontrolle und Sicherheitsrichtlinien variiert von Produkt zu Produkt und von Dienst zu Dienst. 

Der Betrieb – sei es auf der Entwicklungs- oder der IT-Seite – muss tatsächlich eine Vielzahl von Modellen verstehen, um die durchschnittlich vierzehn Anwendungsdienste einzusetzen und zu betreiben, die zum Liefern und Sichern von Apps verwendet werden . Es gibt viele Unterschiede, was in der Vergangenheit dazu geführt hat, dass unzählige Zertifikate erforderlich waren, um die für die Verwaltung dieser Dienste erforderliche Sachkenntnis nachzuweisen. 

Die andere betriebliche Abkehr ist eine Abkehr von diesem Ansatz. Es besteht die Erwartung von Einfachheit, Benutzerfreundlichkeit und Gemeinsamkeiten aller Angebote als Möglichkeit zur Reduzierung der technischen Schulden, die durch gerätespezifische Betriebsmodelle entstehen. Es handelt sich um eine Erwartung einer Standardisierung , nicht von Protokollen und Netzwerkverhalten, die im Bereich der Netzwerkinfrastruktur bereits vorhanden ist. Aber davon, wie wir diese Protokolle und Netzwerkverhalten darstellen .

Dies lässt sich an Umfragen zur Containerisierung erkennen: Fast jeder vierte (24 %) der Befragten nannte die erforderlichen Fähigkeiten als großes Hindernis für die Einführung, und 33 % sagten, es handele sich um ein mäßiges Hindernis. Der Infrastruktursektor – zu dem Container und Container-Orchestrierungssysteme aufgrund ihrer Verbreitung in heutigen Produktionsumgebungen zweifellos zählen – wird durch einen Mangel an Fähigkeiten und den Wunsch nach Geschwindigkeit hin zu standardisierten Betriebsabläufen getrieben. 

Dieser Wunsch und Bedarf zeigt sich in der organischen Übernahme von Kubernetes-Ressourcendateien, die versuchen, die genannten Infrastrukturdienste zu beschreiben. Diese Ressourcen zwingen allen Betreibern die Verwendung eines gemeinsamen (kommerzialisierten) Datenmodells (Formats) zur Beschreibung der Bereitstellung und Konfiguration eines bestimmten Dienstes. Angesichts der Tatsache, dass der IT-Betrieb heute der wichtigste Treiber für die Einführung von Containern (35 %) in Unternehmen ist (laut Diamantis Container Adoption Survey 2019 ) – und damit fast doppelt so einflussreich ist wie Entwickler (16 %) und viermal so einflussreich wie integrierte DevOps-Teams (9 %) – ist es wichtig, diesen Wandel zu erkennen und sorgfältig zu überlegen, wie neue Infrastruktur in eine standardisierte Betriebsumgebung passt (oder nicht passt). 

Mit oder ohne offizielle Bemühungen (von Arbeitsgruppen oder Stiftungen) wird die Kommerzialisierung einen De-facto-Standard in die Praxis umsetzen. Und dieser De-facto-Standard wird ein Standard sein, der die Bedienbarkeit über die Konfigurierbarkeit stellt.