Im Containerland ist deklarative Konfiguration König

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Die interne digitale Transformation ist eine wesentliche Voraussetzung für die digitale Transformation nach außen. Eine der grundlegenden Komponenten der internen digitalen Transformation ist die Automatisierung, die in hohem Maße von der Steuerungsebene abhängt. Auf der Steuerungsebene findet die Automatisierung statt. In den Anfängen der Datenverarbeitung bezeichneten wir sie als „Managementnetzwerk“ und nutzten Protokolle wie SNMP zur Überwachung, Konfiguration und Steuerung.

Heute existiert das Managementnetzwerk zumindest theoretisch noch immer als Medium, über das wir dieselben Aufgaben mithilfe der Steuerungsebene ausführen. Die Steuerungsebene ist eine unübersichtliche Welt aus APIs, Master-Knoten und sogar Nachrichtenwarteschlangen, die es einzelnen Komponenten in einem komplexen verteilten System ermöglichen, sich (fast) automatisch selbst zu verwalten. Sie wird zunehmend ereignisgesteuert, was ein Umdenken gegenüber den früheren zentralisierten Befehls- und Steuerungsmodellen erfordert, die hauptsächlich auf imperativen Verwaltungsmodellen beruhten. Das heißt, ein zentrales System weist Komponenten implizit durch bestimmte API-Aufrufe an, die Änderungen auslösen. Heutige Umgebungen hingegen setzen auf deklarative Modelle, bei denen die Verantwortung für Änderungen auf die einzelnen Komponenten verteilt wird.

In keinem System wird dies deutlicher als in containerisierten Umgebungen. Von außen betrachtet wirken solche Systeme nahezu unkontrolliert: Nachrichten und Ereignisse werden scheinbar wahllos veröffentlicht und ausgelöst, ohne eine übergeordnete Instanz, die vorgibt, wer oder was darauf reagieren soll. Bei der Control Plane geht es nicht mehr so sehr um Kontrolle, sondern vielmehr um die Verteilung über eine Ebene, die eher einem Mesh als den Hub-and-Spoke-Architekturen veralteter Managementsysteme gleicht. In der traditionellen Welt nutzten wir APIs und Protokolle, um Änderungen an Komponenten zu übertragen. In der digitalen, containerisierten Welt nutzen wir APIs, um die Informationen abzurufen, die eine Komponente benötigt, um sich selbst zu ändern.

Diese neue Welt ist reaktiv und verzichtet auf das imperative (API-gesteuerte) Modell der herkömmlichen Steuerungsebene. Stattdessen setzt sie auf ein offeneres, deklaratives Modell, um den gewünschten automatisierten Endzustand zu erreichen.

Das ist nicht überraschend. In dem Maße, in dem wir zunehmend auf einen softwaregesteuerten Ansatz für alles setzen (unter dem Banner von DevOps, Cloud und NFV), müssen wir zugleich eine enorme betriebliche Skalierung bewältigen. Ein imperatives Hub-and-Spoke-Verwaltungsmodell lässt sich nicht effizient skalieren, da die Last sämtlicher Änderungen auf einer zentralen Steuerung liegt, die über eine unübersichtliche Vielzahl von APIs mit einer nahezu unbegrenzten Zahl von Komponenten kommunizieren können muss. Dabei handelt es sich um ein „Push“-Modell, bei dem die Verwaltung (Steuerung) Änderungen an jede betroffene Komponente übermittelt. Sie wird zum Engpass, von dem das gesamte System abhängt.

Ein ereignisgesteuertes Modell, bei dem die Komponenten Änderungen selbst abrufen, ist notwendig, um Skalierbarkeit zu gewährleisten und den Controller zu entlasten. Dies wiederum setzt voraus, dass Komponenten, die an dieser Steuerungsebene teilnehmen sollen, mit einem deklarativen Konfigurationsmodell umgehen können. Denn anstatt Änderungen über eine API zu übertragen (imperativ), führen Container dazu, dass wir Änderungen über deklarative Konfigurationen abrufen. Es liegt in der Verantwortung der Anbieter von Komponenten – ob Open Source oder kommerziell –, Änderungen korrekt zu abonnieren und anschließend die erforderlichen Informationen abzurufen, um die jeweilige Änderung umgehend umzusetzen.

Wenn das nach Infrastructure as Code klingt, dann soll es das auch. Deklarative Konfigurationen sind im Grunde Code oder zumindest Code-Artefakte. Automatisierung basiert zunehmend auf dem Prinzip, die Konfiguration vom zugehörigen Dienst zu entkoppeln. In einem idealen, utopischen Modell wären diese deklarativen Konfigurationen vollständig herstellerunabhängig. Das heißt, sie könnten von jedem Produkt eines beliebigen Anbieters – ob kommerziell oder Open Source – gelesen werden, das den betreffenden Dienst unterstützt. So könnte beispielsweise eine deklarative Konfiguration, die den entsprechenden Dienst (virtuellen Server) und die Anwendungen beschreibt, aus denen sich sein Ressourcenpool zusammensetzt, von Dienst X oder Dienst Y eingelesen und umgesetzt werden.

Kubernetes-Ressourcendateien sind ein gutes Beispiel für ein deklaratives Konfigurationsmodell, in dem beschrieben wird, was gewünscht ist, aber nirgends vorgegeben wird, wie es umgesetzt werden soll. Dies unterscheidet sich deutlich von Systemen, die auf Infrastruktur-APIs basieren und bei denen die Implementierung – mitunter bis ins kleinste Detail – wissen muss, wie die gewünschten Ergebnisse erzielt werden können.

Das deklarative Modell ermöglicht es außerdem, Infrastruktur wie Nutzvieh zu behandeln. Fällt eine Instanz aus, kann sie einfach beendet und durch eine neue ersetzt werden. Die gesamte benötigte Konfiguration befindet sich in der Ressourcendatei; eine Schaltfläche mit der Aufschrift „Speichern Sie Ihre Arbeit, sonst geht sie verloren“ gibt es nicht, weil keine Arbeit verloren gehen kann. Diese Infrastruktur ist nahezu unveränderlich und definitiv kurzlebig. In Systemen, die sich im Minutentakt, wenn nicht sogar im Sekundentakt ändern, ist dies unerlässlich, um die Auswirkungen von Ausfällen zu minimieren.

Da wir uns zunehmend in Richtung automatisierter Systeme bewegen, die Skalierbarkeit und – darf ich es wagen, dies zu behaupten? – Sicherheit bieten, müssen wir deklarative Modelle für die Verwaltung der unzähligen Geräte und Dienste einführen, aus denen der Anwendungspfad für Daten besteht. Andernfalls laufen wir Gefahr, unter einer Lawine betrieblicher Altlasten begraben zu werden, die durch manuelle Integrations- und Automatisierungsmethoden entstehen.

Ü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