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

Wenn Sie alles automatisieren möchten, müssen Sie den deklarativen Ansatz wählen. Hier ist der Grund.

Wir trommeln schon seit geraumer Zeit für die Deklaration, wenn es um Automatisierung geht, insbesondere im Hinblick auf NetOps und Anwendungsdienste. Aber wir haben uns noch nicht wirklich damit befasst, warum es wichtig ist und welche Vorteile es bietet. Ich möchte dies jetzt sofort ändern.

Zur Auffrischung Ihres Gedächtnisses: Derzeit werden zwei Modelle verwendet, um die Konfiguration und Bereitstellung von, na ja, allem zu automatisieren.

Der erste ist der Imperativ, bei dem wir dem Zielsystem genau sagen, wie es das tun soll, was wir tun möchten. Wenn Sie schon einmal einen SSH-Tunnel zu einem System geöffnet und einen bestimmten Satz von Befehlen in die CLI eingegeben haben, haben Sie sich mit dem imperativen Konfigurationsmodell beschäftigt.

Die zweite (und bevorzugte) Methode ist deklarativ. Dabei sagen wir dem Zielsystem, was es tun soll, aber nicht wie. Aus mehreren Gründen wird dieses Modell von den meisten Lösungen zur Netzwerkautomatisierung verwendet. Der wichtigste Grund hierfür ist der enorme Kosten- und Zeitaufwand, der erforderlich ist, um sich mit den Hunderten von möglichen Geräten und Systemen vertraut zu machen und sie zu integrieren, die in einer bestimmten Umgebung vorhanden sein können.

Daher müssen wir in einem imperativen Modell jeden Befehl (oder API-Aufruf) angeben, der zur Konfiguration eines Systems erforderlich ist. In einem deklarativen Modell geben wir (normalerweise) nur Schlüssel-Wert-Paare an, die beschreiben, was wir wollen, und überlassen die Befehle zur Umsetzung einem anderen System.

Kinderleicht, so einfach geht das.

Nun zur Beantwortung der Frage, warum dies wichtig ist. Wenn Sie die Automatisierung aller Abläufe vorantreiben möchten, bietet die Einführung eines deklarativen Modells vier wesentliche Vorteile.

1. Reduzieren Sie menschliche Fehler

Wir wissen, dass etwa 22 % der Ausfälle in der Produktion auf menschliches Versagen zurückzuführen sind. Einige Vorfälle, die ziemlich viel Aufsehen erregten und die ich hier nicht noch einmal wiederholen möchte, waren direkt auf einfache menschliche Fehler zurückzuführen. In einem imperativen Modell, das auf API-Aufrufen basiert, ist jeder davon ein potenzieller Vorfall, der nur darauf wartet, einzutreten. Wenn Sie eine Variable nicht überprüft haben oder vergessen haben, nach einem Fehlercode zu suchen, oder wenn es in einem von hundert anderen möglichen Szenarios vorkommt, kann es zu einem Ereignis kommen, das einen Lebenslauf generiert. Das ist eine schlechte Sache.

Ein deklaratives Modell basiert auf einer Vorlage oder Konfigurationsdatei irgendeiner Art, die analysiert und validiert wird, bevor sie durch API-Aufrufe ausgeführt wird. Zwar können Sie immer noch eine Konfigurationsdatei oder Vorlage durcheinanderbringen, die Möglichkeiten hierfür sind jedoch begrenzt, da Sie den erforderlichen Code reduzieren. Und weniger Code bedeutet im Allgemeinen weniger Möglichkeiten, einen Fehler zu machen.

2. Reduzieren Sie die technische Schuld

Technische Schulden sind diese lustige Metapher, die wir aus der Entwicklung übernommen haben und die uns an die langfristigen Kosten unserer Entscheidungen erinnert. Bei imperativen Modellen steigen die technischen Schulden auf verschiedene Weise an. Zunächst erfolgt die Anbindung der Skripte an die API unseres Zielsystems. Diese API unterstützt wahrscheinlich nichts anderes , was bedeutet, dass wir Skripte auf Systembasis entwickeln. Die Konfigurationsschritte variieren wahrscheinlich auch von App zu App – nicht alles ist HTTP, und nicht jede HTTP-basierte Anwendung erfordert genau dieselbe Dienstkonfiguration. Daher erstellen wir jetzt Skripte für jede App und jedes System einzeln. Das sind eine Menge Drehbücher und eine Menge Schulden, die aufgrund dieser Wahl entstehen.

Umgekehrt kann eine deklarative Methode dasselbe Skript und System für den Bereitstellungsprozess verwenden. Obwohl die Vorlage/Konfiguration wahrscheinlich immer noch anwendungs- und systemspezifisch ist, handelt es sich um eine einzelne Datei. Es eliminiert die Komplexität und Anzahl der Skripte und reduziert so die technische Schuld drastisch. Die Realität ist, dass unsere Entscheidungen immer zu Schulden führen. Das Ziel ist, diese 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 Communities mit feindseligen, verärgerten Entwicklern, die sich über Änderungen an einer API und den damit verbundenen Arbeitsaufwand beschweren. Dasselbe kann (und wird) mit Netzwerk- und Anwendungsdiensten passieren. Wenn Sie also an eine Version der API gebunden sind und sich etwas ändert, wissen Sie was? Sie werden bis zum Sankt-Nimmerleins-Tag Skripte aktualisieren (oder vielleicht auch neu schreiben).

Wenn Sie jedoch ein deklaratives Modell übernommen haben, können Sie wahrscheinlich alle Änderungen an der API ignorieren. Schließlich verwenden Sie die API nicht, um dem System mitzuteilen, wie ein Dienst bereitgestellt werden soll, sondern nur, was bereitgestellt werden soll.

4. Reduzieren Sie die Anforderungen an das Fachwissen

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 und einem virtuellen Server nicht kennen, stecken Sie bereits in Schwierigkeiten, und wir sind gerade erst bei Knoten versus Mitgliedern angekommen. Imperative, API-basierte Methoden erfordern, dass Sie das Zielsystem gut genug verstehen, um sich in dessen Konfiguration zurechtzufinden.

Bei Verwendung eines deklarativen Modells ist weniger Fachwissen über das Zielsystem erforderlich. Dies bedeutet, dass sowohl Entwickler als auch DevOps die Methode eher zur Selbstbedienung von Anwendungen verwenden können. Natürlich benötigen Sie nach wie vor Experten, doch die Anforderungen an die Nutzer der Dienste werden geringer und die Belastung durch Bereitstellung und Einsatz wird auf einen größeren Kreis von Beteiligten verteilt.

Es gibt noch weitere Gründe, warum Sie für Ihre NetOps-Automatisierungsbemühungen ein deklaratives Modell übernehmen möchten, aber diese vier sind die überzeugendsten. Der Grund hierfür ist, dass sie NetOps, dem Unternehmen und den immer mehr Beteiligten zugute kommen, die einen Selfservice-Zugriff auf die Netzwerk- und Anwendungsdienste benötigen, um Apps schneller und sicherer zu machen.