Warum ist ein deklaratives Modell für die NetOps-Automatisierung wichtig?

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Wenn Sie alles automatisieren wollen, sollten Sie auf einen deklarativen Ansatz setzen. Hier erfahren Sie, warum.

Wenn wir über Automatisierung sprechen, insbesondere im Hinblick auf NetOps und Anwendungsdienste, betonen wir schon seit geraumer Zeit immer wieder die Bedeutung eines deklarativen Ansatzes. Doch warum dieser so wichtig ist und welche Vorteile er bietet, haben wir bisher nicht näher beleuchtet. Das möchte ich jetzt nachholen.

Zur Erinnerung: Derzeit werden zwei Modelle verwendet, um die Konfiguration und Bereitstellung von, nun ja, allem zu automatisieren.

Das erste Modell ist imperativ. Dabei geben wir dem Zielsystem genau vor, wie es das tun soll, was wir erreichen möchten. Wenn Sie schon einmal einen SSH-Tunnel zu einem System aufgebaut und dort über die Befehlszeile eine bestimmte Abfolge von Befehlen eingegeben haben, haben Sie das imperative Konfigurationsmodell verwendet.

Der zweite (und bevorzugte) Ansatz ist deklarativ: Dabei teilen wir dem Zielsystem mit, was es tun soll, aber nicht, wie. Dieses Modell wird von den meisten Lösungen zur Netzwerkautomatisierung aus mehreren Gründen verwendet. Der wichtigste davon ist der enorme Kosten- und Zeitaufwand, der erforderlich wäre, um sich mit den Hunderten von möglichen Geräten und Systemen in einer bestimmten Umgebung vertraut zu machen und sie zu integrieren.

In einem imperativen Modell müssen wir also jeden Befehl (bzw. API-Aufruf) angeben, der zur Konfiguration eines Systems erforderlich ist. In einem deklarativen Modell geben wir dagegen lediglich (in der Regel) Schlüssel-Wert-Paare an, die den gewünschten Zustand beschreiben, und überlassen es einem anderen System, sich um die dafür erforderlichen Befehle zu kümmern.

Kinderleicht, ein Klacks.

Nun zur Frage, warum das wichtig ist. Die Einführung eines deklarativen Modells bietet vier wesentliche Vorteile, wenn Sie dazu übergehen, alles zu automatisieren.

1. Menschliche Fehler reduzieren

Wir wissen, dass etwa 22 % der Ausfälle in Produktionsumgebungen auf menschliches Versagen zurückzuführen sind. Einige recht aufsehenerregende Vorfälle, die ich hier nicht noch einmal durchkauen möchte, ließen sich direkt auf einfache menschliche Fehler zurückführen. In einem imperativen Modell, das auf API-Aufrufen basiert, birgt jeder einzelne Aufruf das Potenzial für einen Zwischenfall. Wenn Sie eine Variable nicht überprüft, die Prüfung auf einen Fehlercode vergessen oder eines von hundert anderen möglichen Szenarien übersehen haben, könnte das dazu führen, dass Sie bald Ihren Lebenslauf aktualisieren müssen. Das ist keine gute Sache.

Ein deklaratives Modell basiert auf einer Vorlage oder einer Konfigurationsdatei, die analysiert und validiert wird, bevor sie mithilfe von API-Aufrufen umgesetzt wird. Natürlich können auch in einer Konfigurationsdatei oder Vorlage Fehler auftreten. Da jedoch weniger Code erforderlich ist, gibt es dafür weniger Gelegenheiten. Und weniger Code bedeutet in der Regel auch weniger Fehlermöglichkeiten.

2. Technische Schulden reduzieren

Technische Schulden sind jene anschauliche Metapher aus der Softwareentwicklung, die uns an die langfristigen Kosten unserer Entscheidungen erinnert. Bei imperativen Modellen häufen sich technische Schulden auf verschiedene Weise an. Zunächst einmal sind die Skripte eng an die API unseres Zielsystems gekoppelt. Diese API wird wahrscheinlich nichts anderes unterstützen, was bedeutet, dass wir für jedes System eigene Skripte entwickeln. Auch die Konfigurationsschritte werden sich wahrscheinlich von Anwendung zu Anwendung unterscheiden – nicht alles basiert auf HTTP, und nicht jede HTTP-basierte Anwendung erfordert exakt dieselbe Dienstkonfiguration. Somit erstellen wir nun für jede Anwendung und jedes System eigene Skripte. Das sind eine Menge Skripte und eine Menge Schulden, die sich aufgrund dieser Entscheidung anhäufen.

Im Gegensatz dazu kann bei einem deklarativen Ansatz für den Bereitstellungsprozess dasselbe Skript und System verwendet werden. Auch wenn die Vorlage bzw. Konfiguration wahrscheinlich weiterhin anwendungsspezifisch und systemspezifisch sein wird, handelt es sich dabei nur um eine einzige Datei. Dadurch werden die Komplexität und die Anzahl der Skripte reduziert und somit die technischen Schulden drastisch verringert. In der Realität werden unsere Entscheidungen immer gewisse technische Schulden mit sich bringen; das Ziel besteht darin, sie zu minimieren.

3. Versionskonflikte vermeiden

Wenn Sie Ihre Konfigurations- und Bereitstellungsprozesse an eine API binden, sind Sie an diese Version der API gebunden. Im Internet gibt es zahlreiche Communitys, in denen aufgebrachte, wütende Entwickler ihrem Ärger über Änderungen an einer API und den damit verbundenen Aufwand für die Anpassung ihrer App Luft machen. Dasselbe kann (und wird) auch bei Netzwerk- und Anwendungsdiensten passieren. Wenn Sie also an eine bestimmte Version der API gebunden sind und sich etwas ändert, was glauben Sie, was dann passiert? Sie werden bis zum Sankt-Nimmerleins-Tag Skripte aktualisieren (oder vielleicht sogar neu schreiben) müssen*.

Wenn Sie jedoch ein deklaratives Modell eingeführt haben, können Sie Änderungen an der API wahrscheinlich ignorieren. Schließlich verwenden Sie die API nicht, um dem System mitzuteilen, wie es einen Dienst bereitstellen soll, sondern lediglich, was bereitgestellt werden muss.

4. Anforderungen an Fachwissen reduzieren

Seien wir ehrlich: Wenn ich eine API für einen Netzwerk- oder Anwendungsdienst verwenden möchte, muss ich das System verstehen. Wenn Sie den Unterschied zwischen einer virtuellen IP-Adresse und einem virtuellen Server nicht kennen, haben Sie bereits ein Problem – und dabei sind wir noch kaum beim Unterschied zwischen Knoten und Mitgliedern angelangt. Imperative, API-basierte Methoden setzen voraus, dass Sie das Zielsystem gut genug verstehen, um sich in seiner Konfiguration zurechtzufinden.

Bei Verwendung eines deklarativen Modells sind weniger Fachkenntnisse über das Zielsystem erforderlich. Dadurch können sowohl Entwickler als auch DevOps-Teams diese Methode eher nutzen, um Anwendungen eigenständig bereitzustellen. Natürlich werden weiterhin Experten benötigt, doch die Anforderungen an die Nutzer der Dienste sinken, und die Verantwortung für Bereitstellung und Implementierung verteilt sich auf einen größeren Personenkreis.

Es gibt noch weitere Gründe, warum Sie für Ihre NetOps-Automatisierung auf ein deklaratives Modell setzen sollten, doch diese vier sind die überzeugendsten. Denn davon profitieren NetOps, das Unternehmen und der wachsende Kreis von Beteiligten, die im Self-Service auf Netzwerk- und Anwendungsdienste zugreifen müssen, damit Anwendungen schneller und sicherer laufen.

Ü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