Der Mythos der zentralen Benutzeroberfläche

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Seit ich denken kann – und das ist schon eine ganze Weile –, erliegt die IT dem verlockenden Ruf einer zentralen Benutzeroberfläche, über die sich die gesamte Infrastruktur einsehen und steuern lässt. Wie der Heilige Gral wurde sie jedoch nie gefunden, und viele IT-Fachleute zweifeln inzwischen daran, dass es sie überhaupt gibt.

Die digitale Transformation hat diesem mythischen Managementkonzept endgültig den Garaus gemacht und stattdessen ein neues hervorgebracht: eine zentrale Steuerungsebene.

Die gute Nachricht ist, dass eine zentrale Steuerungsebene – anders als die einheitliche Benutzeroberfläche, nach der unerschrockene IT-Pioniere früher suchten – durchaus in greifbarer Nähe sein könnte. Denn sie basiert nicht auf einer grafischen Benutzeroberfläche, sondern auf der API.

Und zwar nicht irgendeine API, sondern eine deklarative API.

Um zu verstehen, warum das so ist, möchte ich Sie ins Jahr 2010 zurückversetzen, als der Begriff „Infrastructure 2.0“ in aller Munde war.

Auf der untersten Ebene der Architektur befindet sich Infrastructure 2.0. Infrastructure 2.0 zielt darauf ab, Dynamik und Zusammenarbeit innerhalb der Netzwerk- und Anwendungsbereitstellungsinfrastruktur zu ermöglichen. Dabei werden grundlegende Rechenzentrumskomponenten, die traditionell – aus Kommunikations- und Verwaltungssicht – voneinander getrennt sind, in die Lage versetzt, sich zu vernetzen und zusammenzuarbeiten. Dies wird in erster Linie erreicht durch offene, standardbasierte APIs mit einem granularen Satz betrieblicher Funktionen, die über verschiedene programmatische Verfahren aufgerufen werden können, etwa über Orchestrierungssysteme, benutzerdefinierte Anwendungen oder durch die Integration in herkömmliche Lösungen für die Rechenzentrumsverwaltung. Bei Infrastructure 2.0 geht es darum, das Netzwerk sowohl aus Verwaltungs- als auch aus Laufzeitperspektive (Ausführung) intelligenter zu machen. Im Zusammenhang mit Cloud und IT as a Service liegt der Schwerpunkt jedoch vor allem auf der Verwaltung.

Infrastructure 2.0 umfasst die Bereitstellung von Diensten für alles – von Routern bis zu Switches, von Load Balancern bis zur Anwendungsbeschleunigung, von Firewalls bis zu Komponenten für die Sicherheit von Webanwendungen und zur Serverinfrastruktur (physisch und virtuell). Im Kern handelt es sich dabei um API-fähige Komponenten.

Aus <https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait>

Kommt Ihnen das bekannt vor? Wir nennen es heute nicht mehr Infrastruktur 2.0, sondern „Continuous Deployment“, „Automatisierung“ und verwenden andere Begriffe aus dem DevOps-Umfeld. Das Konzept ist jedoch dasselbe. In dieser Idee liegt auch der Grund dafür, dass eine zentrale, einheitliche Benutzeroberfläche – ein sogenannter „Single Pane of Glass“ – nie Wirklichkeit geworden ist. Denn damit ein solches sagenumwobenes Konstrukt existieren könnte, müsste eine einzige Lösung eine Vielzahl von Netzwerk-, Anwendungsdienst- und Sicherheitslösungen einbinden – und zwar durch manuelle Integration.

Dazu würde es niemals kommen.

Ehrlich gesagt, wäre es trotz der API-Unterstützung für den Großteil dieser Infrastruktur nie dazu gekommen. Warum? Weil all diese APIs imperativ und genauso eng an das Objektmodell des jeweiligen Geräts gekoppelt waren wie die zugehörigen grafischen Benutzeroberflächen. Imperative APIs sind grundsätzlich an geräte- bzw. dienstspezifische Objektmodelle gebunden, die denjenigen, die sie nutzen möchten, ein hohes Maß an betrieblichem Fachwissen abverlangen. Stellen Sie sich nun den Allrounder in Ihrer IT-Organisation vor, dem Sie zutrauen, Router, Switches, Sicherheitsgeräte und fünf verschiedene Kategorien von Anwendungsdiensten unterschiedlicher Anbieter zu verwalten.

Genau. Ein solches Wesen ist wie Bigfoot: Man hört oft davon, doch seine Existenz wurde nie bewiesen.

Was meine ich damit? Folgendes:

Die Art und Weise, wie wir beispielsweise einen Pool, eine VIP (virtuelle IP-Adresse) oder ein VLAN (virtuelles LAN) darstellen, unterscheidet sich davon, wie Cisco, Citrix oder Juniper dieselben Netzwerkobjekte darstellen. Tatsächlich kann sich sogar unsere Terminologie unterscheiden: Wir verwenden „Pool“, während andere ADC-Anbieter dasselbe Konzept als „Farm“ oder „Cluster“ bezeichnen. Kommt noch die Virtualisierung hinzu, entsteht ein weiterer Satz von Begriffen, die häufig im Widerspruch zu denen der Anbieter von Netzwerkinfrastruktur stehen. „Virtueller Server“ bedeutet bei einem Anbieter von Anwendungsbereitstellung etwas völlig anderes als bei einem Virtualisierungsanbieter wie VMWare oder Microsoft.

Aus <https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards>

DAS ist der Grund, warum uns schöne Dinge wie eine zentrale Benutzeroberfläche verwehrt bleiben. Denn der Branche fehlt eine einheitliche Perspektive, aus der sie die Infrastruktur betrachtet.

Dieser Beitrag soll Sie jedoch weder deprimieren noch Sie auf einen Weg führen, der Sie zu einem IT-Dasein verdammt, das für immer von der Verwaltung einzelner Geräte geprägt ist. Ganz im Gegenteil. Deklarative – wirklich deklarative – APIs können eine zentrale Steuerungsebene ermöglichen.

Doch dafür müssen wir uns von der Vorstellung lösen, dass deklarativ bedeutet, unsere Gerätekonfigurationen in JSON oder YAML zu kodieren. Das ist nicht wirklich deklarativ, da es weiterhin betriebliches Fachwissen voraussetzt, das an gerätespezifische Objektmodelle gebunden ist – und von niemand anderem eingelesen und genutzt werden kann.

Lassen Sie mich die Ressourcenbeschreibungen von Kubernetes Service und Endpoint als Beispiel für ein deklaratives Modell heranziehen:

Alles, was ich zum Konfigurieren eines virtuellen Servers benötige, steht genau hier in diesen sehr prägnanten und implementierungsunabhängigen Definitionen. Die externalIP ist die virtuelle IP-Adresse – also die Adresse, mit der der Benutzer oder die mobile App kommuniziert. Der Name „my-Service“ beschreibt einen virtuellen Server, wobei spec die Netzwerkdetails angibt, etwa welche ports verwendet werden sollen und welcher Pool („MyApp“). Die Endpoint-Ressourcen beschreiben die einzelnen Knoten, aus denen „my-service“ besteht, und stellen die Mitglieder für den Pool „MyApp“ bereit. Das Einzige, was hier noch fehlt, ist eine Möglichkeit, für Dienste, die mehr als Round Robin unterstützen, einen Lastverteilungsalgorithmus auszuwählen. Und wir könnten den „spec“-Abschnitt der Dienstbeschreibung problemlos um eine Option „algorithm: RR | WRR | LC | FR“ erweitern, die universell auf alle Lastverteilungslösungen anwendbar ist. So. Fertig.

Theoretisch kann ich dieselbe Ressource an jede von zehn verschiedenen Load-Balancing-Lösungen übergeben, und jede davon würde selbst bestimmen, wie die Absicht der Beschreibung modelliert und umgesetzt werden soll – nämlich einen virtuellen Dienst unter 80.11.12.10 an Port 80 zu konfigurieren, der HTTP-Anfragen auf zwei Anwendungsinstanzen unter 1.2.3.4 und 2.3.4.5 an Port 80 verteilt.

Eine andere Möglichkeit, sich das vorzustellen, ist der Unterschied zwischen „Ich hätte gern eine Pizza mit Peperoniwurst“ und der umständlicheren Variante: „Ich möchte, dass Sie einen Pizzateig zubereiten und ihn anschließend zu einem Kreis mit einem Durchmesser von 10 Zoll ausrollen. Bestreichen Sie ihn mit Tomatensoße. Belegen Sie ihn dann mit Mozzarella. Verteilen Sie nun die Peperoniwurst darauf. Backen Sie die Pizza 15 Minuten lang bei 425 Grad.“

Eine dieser Varianten ist einfacher und erspart Ihnen die Details. Bei der anderen müssen Sie nicht nur wissen, was Sie wollen – eine Pizza mit Peperoniwurst –, sondern auch, wie man sie zubereitet. Genau das ist operative Fachkompetenz.

Wie bei der Bestellung einer Pizza ist die Kubernetes-Ressourcenbeschreibung allgemein gehalten. Sie schreibt dem Gerät, das diese Ressource verarbeitet, weder ein bestimmtes Objektmodell noch eine bestimmte Implementierungsmethode vor. Sie beschreibt, was vorhanden sein muss, schränkt aber in keiner Weise ein, wie ich es implementieren könnte.

Wirklich deklarativ zu sein bedeutet, die Möglichkeit zu bieten, Absicht und den gewünschten Endzustand zu kommunizieren. Irgendwann werden wir einfach sagen können: „Konfiguriere einen virtuellen Dienst für ‚my-app‘“, und voilà! Mithilfe von Metadaten, Anwendungs-Tags und automatisierter, intelligenter Erkennung wird sich der Dienst von Grund auf selbst konfigurieren*.

Wenn wir jemals dieses Nirwana einer zentralen Steuerungsebene erreichen wollen, müssen wir uns an die Arbeit machen und neutrale deklarative Spezifikationen entwickeln, die es überflüssig machen, jedes Gerät im Rechenzentrum über eine imperative API zu integrieren. Denn die API-Integration einzelner Geräte unterscheidet sich letztlich kaum von der Verwaltung einzelner Geräte.

Wir wollen gute Lösungen. Wir wollen eine einheitliche, zentrale Steuerungsebene. Doch um dieses Ziel zu erreichen, muss die Branche mehr tun, als nur zustimmend in Richtung deklarativer Ansätze zu nicken, und erkennen: Wenn niemand sonst Ihre deklarative Schnittstelle einlesen und nutzen kann, ist sie von vornherein nicht wirklich deklarativ.

*Man wird ja wohl noch träumen dürfen, oder?

Ü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