Im Containerland ist die deklarative Konfiguration König

Die digitale Transformation im Inneren ist von entscheidender Bedeutung, um die digitale Transformation im Äußeren zu ermöglichen. Eine der grundlegenden Komponenten der internen digitalen Transformation ist die Automatisierung, die in hohem Maße auf der Steuerungsebene basiert. Die Automatisierung findet auf der Steuerebene statt. In den alten Computertagen bezeichneten wir es als „Verwaltungsnetzwerk“ und verwendeten Protokolle wie SNMP zur Überwachung, Konfiguration und Steuerung.

Heute existiert das Verwaltungsnetzwerk zumindest theoretisch noch immer als Medium, über das wir dieselben Aufgaben über die Steuerebene ausführen. Die Steuerebene ist ein unübersichtliches Gebiet aus APIs, Masterknoten und sogar Nachrichtenwarteschlangen, die es einzelnen Komponenten in einem komplexen verteilten System ermöglichen, sich (fast) automatisch selbst zu verwalten. Sie erfolgt zunehmend ereignisgesteuert, was ein Umdenken gegenüber den zentralisierten Befehls- und Kontrollmodellen der Vergangenheit erfordert, die sich in erster Linie auf imperative Managementmodelle stützten. Das heißt, ein zentrales System weist Komponenten implizit durch bestimmte API-Aufrufe an, Änderungen herbeizuführen. Die heutigen Umgebungen basieren dagegen auf deklarativen Modellen, die die Verantwortung für Änderungen selbst verteilen.

In keinem System ist dies deutlicher als in Containerumgebungen. Von außen betrachtet wirken solche Systeme beinahe abtrünnig; Nachrichten und Ereignisse werden nach Belieben veröffentlicht und gesendet, ohne dass es einen Oberherrn gibt, der bestimmt, wer oder was darauf reagieren soll. Bei der Kontrollebene geht es nicht mehr so sehr um Kontrolle, sondern vielmehr um die Verteilung über eine Ebene, die eher einem Netz als den Hub-and-Spoke-Architekturen archaischer Verwaltungssysteme entspricht. In der traditionellen Welt haben wir APIs und Protokolle verwendet, um Änderungen an Komponenten vorzunehmen. In der digitalen, containerisierten Welt nutzen wir APIs, um die Informationen abzurufen, die eine Komponente für ihre Selbständerung benötigt.

Diese neue Welt ist reaktiv und verzichtet auf das imperative (API-gesteuerte) Modell der traditionellen Steuerungsebene. Stattdessen verlässt sie sich auf ein offeneres, deklarativeres Modell, um den gewünschten automatisierten Endzustand zu erreichen.

Das ist nicht überraschend. Da wir bei allen Bereichen zunehmend einen softwaregesteuerten Ansatz verfolgen (unter dem Deckmantel von DevOps, Cloud und NFV), mussten wir uns gleichzeitig mit enormen betrieblichen Größenordnungen auseinandersetzen. Ein imperatives Hub-and-Spoke-Managementmodell lässt sich nicht effizient skalieren, da die Last für alle Änderungen auf einem zentralen Controller liegt, der über eine verwirrende Anzahl von APIs mit einer nahezu unbegrenzten Gruppe von Komponenten kommunizieren kann. Dies ist ein „Push“-Modell, bei dem der Manager (Controller) Änderungen an jede betroffene Komponente überträgt. Es wird zum Engpass, der über Erfolg oder Misserfolg des gesamten Systems entscheidet.

Zur Skalierung und Entlastung des Controllers ist ein ereignisgesteuertes Modell erforderlich, das auf Pull-by-Komponenten basiert. Dies erfordert wiederum, dass Komponenten, die an dieser Steuerungsebene teilnehmen möchten, mit einem deklarativen Konfigurationsmodell zurechtkommen. Denn statt Änderungen über eine API zu pushen (imperativ), drängen uns Container dazu, Änderungen stattdessen über deklarative Konfigurationen zu pullen. Es liegt in der Verantwortung der Komponentenanbieter (ob Open Source oder kommerziell), die Änderungen korrekt zu abonnieren und dann die entsprechenden Informationen abzurufen, die für die sofortige Implementierung dieser Änderungen erforderlich sind.

Wenn Sie von Infrastruktur als Code sprechen, liegen Sie richtig. Deklarative Konfigurationen sind grundsätzlich Code oder zumindest Code-Artefakte. Automatisierung baut zunehmend auf dem Prinzip auf, Konfiguration und Dienst voneinander zu trennen. In einem idealen Modell sind diese deklarativen Konfigurationen vollkommen neutral. Das bedeutet, jede unterstützende Software eines beliebigen Anbieters (kommerziell oder Open Source) kann sie lesen. Zum Beispiel könnte eine deklarative Konfiguration, die den passenden Dienst (virtueller Server) und die Anwendungen beschreibt, die dessen Ressourcenpool nutzen, von Dienst X oder Dienst Y verarbeitet und umgesetzt werden.

Kubernetes-Ressourcendateien sind ein gutes Beispiel für ein deklaratives Konfigurationsmodell, bei dem beschrieben wird, was erreicht werden soll, ohne festzulegen, wie genau. Das unterscheidet sich deutlich von Systemen, die auf Infrastruktur-APIs bauen und bei denen Sie genau wissen müssen, wie Sie die gewünschten Ergebnisse erzielen.

Das deklarative Modell erlaubt es Ihnen auch, Infrastruktur wie nutzbare Ressourcen zu behandeln. Fällt eine Instanz aus, können Sie sie problemlos beenden und eine neue bereitstellen. Alle notwendigen Konfigurationen liegen in der Ressourcendatei; einen „Speichern, sonst geht etwas verloren“-Button brauchen Sie nicht, weil keine Daten verloren gehen. Diese fast unveränderliche, klar entbehrliche Infrastruktur ist für Systeme, die sich jede Minute, wenn nicht sogar jede Sekunde ändern, unerlässlich, um Ausfallfolgen zu minimieren.

Da wir uns immer mehr in Richtung automatisierter Skalierungs- und – darf ich das behaupten? – Sicherheitssysteme bewegen, müssen wir uns für die Verwaltung der unzähligen Geräte und Dienste, aus denen der Anwendungsdatenpfad besteht, auf deklarative Modelle stützen. Sonst laufen wir Gefahr, unter einer Lawine von Betriebsschulden begraben zu werden, die durch manuelle Integrations- und Automatisierungsmethoden entstehen.