3. Architektonisches Denken#

Dieses Kapitel stellt das Fundament dieses Buches vor. Es erklärt, warum Sie diese Denkweise übernehmen müssen, stellt ein vom Network Automation Forum (NAF) vorgeschlagenes Referenzrahmenwerk vor und zeigt, wie Sie es in Ihren Projekten einsetzen können.

Teil 2 taucht tief in diese Themen ein. In diesem Kapitel werden wir sie nur vorstellen, um ein übergeordnetes Bild zu vermitteln, bevor wir ins Detail gehen. Das ist wichtig, weil das Gesamtbild hilft, die Zusammenhänge zu erkennen, sobald wir jeden Baustein beschreiben.

Aber ich bin ein starker Befürworter davon, das WARUM vor dem WAS zu verstehen, also lassen Sie uns zunächst die Gründe für eine Architektur verstehen.

3.1. Warum eine Referenzarchitektur wichtig ist#

“Nur die Gebildeten sind frei.” - Epiktet

Eine Netzwerkautomatisierungslösung ist eine Kombination mehrerer Bestandteile, von denen jeder eine Rolle spielt. In der Netzwerktechnik sind wir einfache oder monolithische Lösungen gewohnt, die als Allround-Boxen versuchen, alle Probleme zu lösen. Das mag bis zu einem gewissen Grad stimmen, aber nichts kann alle unterschiedlichen Herausforderungen und Anwendungsfälle allein lösen. Wenn Ihr Anwendungsfall also nicht zu den beliebtesten gehört, müssen Sie möglicherweise anpassen oder erweitern.

Ohne eine klare Referenzarchitektur stehen Teams oft vor einem vorhersehbaren Satz von Problemen:

• Doppelte Arbeit: Mehrere Teams entwickeln unabhängig voneinander ähnliche Tools (Datenquellen, doppelte Skripte, redundante Monitoring-Systeme) und verschwenden Ressourcen bei inkonsistenten Schnittstellen.
• Integrationslücken: Tools kommunizieren nicht sauber miteinander und erzwingen teure benutzerdefinierte Integrationsarbeit.
• Unklare Verantwortlichkeiten: Es ist unklar, welches Tool Observability, Orchestrierung oder Zustandsverwaltung übernehmen soll, was zu Verwirrung und gegenseitigen Schuldzuweisungen führt.
• Schwer erweiterbar: Das Hinzufügen neuer Fähigkeiten oder Tools erfordert ein Überdenken des gesamten Systems.
• Wissenssilos: Verschiedene Teams verwenden unterschiedliche mentale Modelle, was die Einarbeitung neuer Mitglieder oder die Wartung von Lösungen erschwert.

Eine Referenzarchitektur löst diese Probleme, indem sie ein einheitliches klares mentales Modell dafür bereitstellt, wie Automatisierungssysteme organisiert werden sollten. Sie definiert:

• Was jede Komponente tun soll -> ihre Verantwortlichkeiten
• Wie Komponenten interagieren -> ihre Schnittstellen und Datenflüsse
• Wo Sie Entscheidungen treffen können -> welche Tools verwendet werden
• Wo Konsistenz erforderlich ist -> wie Komponenten miteinander kommunizieren

Eine Referenzarchitektur ist für Netzwerkingenieure nichts Neues. Wir alle sind mit dem geliebten OSI-Modell aufgewachsen. Das OSI-Modell bietet einen schrittweisen, geschichteten Ansatz zur Diagnose und zum Verständnis von Netzwerkproblemen, weil jede Schicht unterschiedliche Verantwortlichkeiten und Belange hat. Netzwerkexperten verstehen intuitiv, dass diese Separation of Concerns komplexe Systeme handhabbar macht.

In der Netzwerkautomatisierung brauchen wir etwas Ähnliches, das anleiten kann, wie Lösungen entwickelt und miteinander verbunden werden sollen. Es hilft Teams, konsistente Entscheidungen zu treffen, Komponenten projektübergreifend wiederzuverwenden und ihre Automatisierungsfähigkeiten weiterzuentwickeln, ohne das Rad jedes Mal neu erfinden zu müssen.

3.2. Eine Netzwerkautomatisierungsarchitektur#

Folglich brauchen wir eine Architektur. Aber beachten Sie das “Eine” im Abschnittstitel: Es gibt nicht nur eine Architektur, es gibt viele. Eine Architektur ist einfach ein Referenzrahmen: eine Möglichkeit, das Denken zu strukturieren und konsistente Entscheidungen zu leiten. Ich habe zu drei Initiativen beigetragen:

• Network to Code Referenzarchitektur: ein kollektives Bemühen des NTC-Architekturteams (dem ich vier Jahre lang angehörte), das entwickelt wurde, um effiziente und verständliche Netzwerkautomatisierung für eine breite Palette von Anwendungsfällen zu unterstützen.
• Network Automation and Programmability, 2. Auflage von O’Reilly: ein Bemühen, alle Buchinhalte mit meinen Mitautoren zu verbinden: Matt Oswalt, Scott S. Lowe und Jason Edelman.
• NAF Framework: ein Community-Projekt unter dem Dach des NAF, das gemeinsam mit Wim Henderickx, Dinesh Dutt, Claudia de Luna, Ryan Shaw und Damien Garros geleitet wurde, mit dem Ziel, sowohl Neueinsteigern als auch erfahrenen Praktikern zu helfen, Automatisierungslösungen strukturiert und wiederholbar aufzubauen.

Über diese Iterationen hinweg habe ich mich darauf konzentriert, Konsistenz beizubehalten und aus jeder Weiterentwicklung zu lernen. Alle drei Ansätze sind nützlich. Ich schlage jedoch vor, das NAF Framework als aktuelle Best Practice zu verwenden: Es ist community-getrieben, herstellerunabhängig und breit anwendbar. Es konsolidiert jahrelange kollektive Lernerfahrung und wird von einer engagierten und wachsenden Community aktiv gepflegt.

Die drei ergänzen sich gegenseitig statt zu konkurrieren. Ein kurzer Vergleich hilft zu klären, wann jeder am relevantesten ist:

Das NAF Framework definiert die Verträge zwischen Blöcken und lässt Implementierungsentscheidungen offen. Die NTC-Architektur füllt diese Entscheidungen mit spezifischen Tool-Empfehlungen. Wenn Ihr Team NTC-Tools verwendet, gelten beide gleichzeitig ohne Konflikt.

Das NAF Framework schlägt die folgende Architektur vor:

block-beta
    columns 7
    
	space:1	
    block:layer1:5
        Presentation["Presentation"]
    end
	space:1

    space:7

    
    block:Observability:2
        columns 2
        %% ObsLabel["Observabilit"]:2
        ObservedState[("Beobachteter Zustand")]:1
        ObservedLogic["Beobachtungslogik"]:1
    end

	space
    
	block:Orchestration:1
		columns 1
		OrchLabel["Orchestrierung"]:1
	end

	space
    
    block:Intent:2
        columns 2
        %% IntLabel["Intent"]:2
        IntendedState[("Gewünschter Zustand")]:1
        IntendedLogic["Intent-Logik"]:1
    end
    
    space:7

	space

    
    Collector["Collector"]:2
	space
    Executor["Executor"]:2
	space
    
	space:7
	space:1
    
    block:layer4:5
        NetworkInfra["Netzwerkinfrastruktur"]
    end
    
    Presentation <--> Observability
    Presentation <--> Orchestration
    Presentation <--> Intent
    
    Observability <--> Orchestration
    Orchestration <--> Intent
    
    Collector --> Observability
    Collector <--> Orchestration
	NetworkInfra --> Collector
    
    Orchestration --> Executor
    Intent --> Executor
    Executor --> NetworkInfra
    
    classDef darkStyle fill:#5a4149,stroke:#4a9eff,stroke-width:2px,color:#e8e8e8,font-size:20px,font-weight:bold
    
    class Presentation,NetworkInfra,ObsLabel,IntLabel,Collector,Executor,ObservedState,ObservedLogic,IntendedState,IntendedLogic,OrchLabel darkStyle

Diese Architektur enthält die folgenden Blöcke gemäß den Definitionen des Dokuments:

• Intent (Architectural Block): Definiert die Logik zur Verwaltung und die Persistenzschicht zur Speicherung des Desired State des Netzwerks, einschließlich Konfigurations- und Betriebserwartungen.
• Executor: Umfasst die tatsächlichen Aufgaben, die auf das Netzwerk angewendet werden, um Änderungen durchzuführen (Konfiguration aktualisieren), geleitet vom gewünschten Zustand.
• Collector: Im Gegensatz zum Executor konzentriert sich diese Komponente auf das Abrufen (Lesen) des Actual State des Netzwerks.
• Observability: Persistiert den Actual State des Netzwerks und definiert die Logik zu seiner Verarbeitung.
• Orchestrator: Definiert, wie Automatisierungsaufgaben koordiniert und als Reaktion auf Ereignisse ausgeführt werden.
• Presentation (Layer): Bietet die Schnittstellen, über die Benutzer mit dem System interagieren, einschließlich Dashboards, grafischer Benutzeroberflächen (ITSM) und Command Line Interface (CLI)-Tools.

Diese Architektur ist nicht willkürlich; sie ist die natürliche Konsequenz der Anwendung von Software-Engineering-Prinzipien auf den Netzbetrieb.

Das NAF-Framework soll Netzwerkautomatisierungsarchitekten helfen, ihre Lösungen zu organisieren, indem es die Funktionalitäten für jedes Modul referenziert und MUSTs, SHOULDs und MAYs (im RFC-Stil) definiert. Dann können Sie entscheiden, wie Sie diese implementieren, um Ihre eigenen Anwendungsfälle zu lösen.

Mehrere Komponenten zu haben bedeutet nicht, dass Sie ein Tool pro Komponente auswählen müssen. In vielen Fällen könnten Sie ein Tool verwenden, das verschiedene Funktionalitäten implementiert, aber das bringt Kompromisse mit sich, die Sie verstehen (und anerkennen) müssen.

Nun werden wir die verschiedenen Blöcke vorstellen.

3.2.1. Intent oder Source of Truth#

Der Intent umfasst alle Daten, die alle notwendigen Informationen definieren, die benötigt werden, um Ihr Netzwerk von null bis vollständig betriebsbereit zu bringen, und umfasst alle verschiedenen Lebenszyklusstatus, von der Vor-Provisionierung über das Bootstrap bis hin zum vollständig betriebsbereiten Zustand und der endgültigen Außerbetriebnahme aller Arten von Netzwerkdiensten.

Die Architektur nennt es Intent, aber ich verknüpfe es mit einem anderen gängigen Begriff: Source of Truth (SoT). Der SoT-Begriff wird manchmal missverstanden, und ich möchte zunächst klarstellen, was die SoT oder der Intent ist (ich werde sie im gesamten Buch austauschbar verwenden).

Wie Sie sich vorstellen können, könnte dies sehr unterschiedliche Daten umfassen, einschließlich Geräte, IP-Adressierung, Rechenzentrumsinfrastruktur (Racks, Kabel), Routingprotokolle, virtualisierte Dienste, Geheimnisse, Betriebsgrenzen, Konfigurationstemplates und Dienst- oder Richtlinienabstraktionen. Ein wichtiger Aspekt ist, dass diese Daten strukturiert sein müssen, um von Maschinen verstanden zu werden. Dann muss sie Erstellen-, Lesen-, Aktualisieren- und Löschen-Operationen unterstützen und über eine standardisierte, gut dokumentierte Application Programming Interface (API) wie Representational State Transfer (REST) oder GraphQL zugänglich sein.

In Analogie zur manuellen Netzwerkverwaltung entspricht dies hauptsächlich der Rolle des Netzwerkarchitekten, der das Design und das Netzwerkschema definiert, oder des Netzwerkplaners, der die BOM für eine neue Netzwerkbereitstellung definiert.

Idealerweise sollte diese Komponente eine konsistente und einheitliche Sicht auf den gewünschten Zustand bieten, auch wenn die Daten über mehrere Datenquellen verteilt sind. Diese Datenquellen, die ich als Systems of Record (SoR) bezeichne, sind die eigentlichen Eigentümer der Daten. Das ist also eines der ersten Dinge, die zu klären sind: Es ist äußerst selten, nur eine Datenquelle zu haben, aber die Daten müssen konsistent sein, wenn sie konsolidiert werden. Datenverwaltung ist ein komplexes Thema, das Data-Governance-Funktionen erfordert, einschließlich einer Form von Metadaten wie Zeitstempel, Datenherkunft, Dateneigentümerschaft und Gültigkeitszeiträume, um das Verstehen und Verwalten dieser Daten zu erleichtern.

Darüber hinaus sollte dieser Block, verbunden mit den Funktionen, die vertrauenswürdige Netzwerkautomatisierung ermöglichen, transaktionalen und versionierten Zugriff auf die Daten bieten, der vorhersehbare und zuverlässige Netzwerkautomatisierungsprozesse ermöglicht.

Wenn Sie verstehen möchten, welche tatsächlichen Tools in diese Kategorie passen könnten, hier sind einige Beispiele: CSV/YAML/JavaScript Object Notation (JSON)-Dateien, Git, NetBox, Nautobot, Infrahub, Infoblox oder allgemeine Datenbanken.

Siehe Kapitel 4 für einen tiefen Einblick in den Aufbau und die Verwaltung Ihrer Source of Truth.

3.2.2. Executor#

Der Executor ist dafür zuständig, den gewünschten Zustand aus dem Intent in den tatsächlichen Netzwerkzustand zu implementieren (zu schreiben), und interagiert mit dem Netzwerk über verschiedene Schnittstellen wie SSH, NETCONF, gNMI/gNOI und REST-APIs.

In Fortsetzung der Analogie zur manuellen Netzwerkverwaltung wäre der Executor der Netzwerkingenieur, der die endgültige Netzwerkkonfiguration vorbereitet und sich über CLI mit dem Netzwerkgerät verbindet, um die Konfigurationsbefehle einzugeben.

Dies ist jedoch nicht so einfach wie das Kopieren und Einfügen von Daten von einem Ort (dem Intent) zu einem anderen (dem Netzwerk). Es gibt viele zu berücksichtigende Operationen, von Netzwerkänderungen bis hin zum Neustart oder Upgrade von Systemen. Auch wenn die Referenzdaten meistens aus dem Intent-Block stammen, kann in einigen Fällen die von Observability stammenden beobachteten Daten diese Komponente beeinflussen, so dass beides kombiniert werden muss.

Der Executor könnte beispielsweise die Geräteerreichbarkeit vor dem Versuch von Änderungen validieren, Failover-Logik basierend auf dem aktuellen Netzwerkzustand anpassen oder die Ausführung überspringen, wenn Observability zeigt, dass ein kritischer Abhängigkeitsdienst ausgefallen ist. Dieses Feedback von Observability stellt sicher, dass Automatisierungsentscheidungen durch reale Netzwerkbedingungen informiert werden, nicht nur durch den Intent allein.

Ähnlich wie beim Intent sollte diese Komponente Funktionen wie Dry-Run, transaktionale Änderungen und Idempotenz (über deklarative oder imperative Ansätze) bereitstellen, die beim Aufbau von Automatisierungssystemen helfen, denen Netzwerkingenieure vertrauen können. Dies ist normalerweise die Komponente, um die sich Netzwerkingenieure (anfangs) am meisten sorgen, weil sie diejenige ist, die das Netzwerk tatsächlich “verändert”.

Tools, die hauptsächlich in diese Kategorie passen, sind Ansible, Terraform/OpenTofu, oder jede Art von Skripten, die Bibliotheken wie Netmiko, Scrapli oder Napalm nutzen, oder sogar eine Kubernetes-CRD (Custom Resource).

Gehen Sie zu Kapitel 5, um Ausführungsframeworks, Idempotenzlmuster und Implementierungsstrategien zu erkunden.

3.2.3. Collector#

Analog zum Executor ist der Collector dafür zuständig, die tatsächlichen Betriebsdaten aus dem Netzwerk über verschiedene Schnittstellen und Protokolle abzurufen (dieselben Schnittstellen wie der Executor, plus andere wie SNMP, Syslogs oder andere flussbasierte Telemetrie).

Das Ziel all dieser Daten ist der Observability-Block, wo die Daten verwendet werden, um Automatisierungsentscheidungen zu ermöglichen.

Ein wichtiges Thema hier, das normalerweise nicht berücksichtigt wird, ist die Notwendigkeit normalisierter Daten für Vergleichbarkeit. Das Erhalten konsistenter Metriknamen für alle Hersteller (system_version definiert die OS-Version unabhängig von der Plattform) und konsistenter Metadaten zur Ermöglichung fortgeschrittener Datenverarbeitung ist entscheidend.

Beispiele für Tools, die in diese Kategorie passen, sind Telegraf, Vector, gNMIc, PMACCT, goFlow, Akvorado, oder jede Art von Skript, das Bibliotheken nutzt, um Daten aus dem Netzwerk abzurufen.

Aufgrund ihrer Affinität werde ich den Collector zusammen mit dem nächsten Baustein, Observability, in Kapitel 6 behandeln. Collector und Observability sind architektonisch eigenständig, aber betrieblich untrennbar: Jede Designentscheidung darüber, wie Daten gesammelt werden, wird davon bestimmt, was die Observability-Schicht verarbeiten muss. Sie zusammen zu behandeln bewahrt diese Abhängigkeit.

3.2.4. Observability#

Eng mit dem Collector verbunden (in vielen Fällen zusammen gesehen) empfängt Observability die gesammelten Daten, unterstützt deren Persistenz und bietet programmatischen Zugriff zur Unterstützung fortgeschrittener Analysen, Berichte und Fehlerbehebungs-Workflows, idealerweise mit leistungsfähigen Abfragesprachen (wie PromQL).

Die Daten aus diesem Block müssen relevante Diskrepanzen zwischen dem Desired State und dem Actual State des Netzwerks offenlegen und Ereignisse (oder Alerts) erzeugen, die Abhilfesysteme auslösen können.

In Fortsetzung der analogen Betrachtung zur manuellen Netzwerkverwaltung entspricht dies der Rolle des Network Operations Center, das den tatsächlichen Zustand des Netzwerks prüft und entsprechend reagiert.

Darüber hinaus können die beobachteten Daten mit kontextuellen Informationen aus dem gewünschten Zustand angereichert werden, einschließlich anderer Drittanbieterquellen (z.B. EoL-Informationen, CVEs, Wartungsbenachrichtigungen usw.), was die Analyse verbessert und eine genauere Datenkorrelation ermöglicht.

Im traditionellen Netzwerkmonitoring wurden alle Funktionalitäten von Observability (und Sammlung) in eine große Box integriert (Tools wie Nagios, LibreNMS, Spectrum usw.).

Derzeit gewinnen vielfältigere integrierende Systeme an Popularität: Prometheus und InfluxDB als beliebte Time Series Database (TSDB), Elasticsearch und andere verwandte Systeme, die Alerts verwalten (Alertmanager) und visualisieren (Grafana, Kibana). Das hat zu einigen beliebten Stacks geführt: ELK, TIG oder TPG.

Erfahren Sie mehr über Monitoring-Architektur, Alert-Strategien und Observability-Best-Practices in Kapitel 6.

3.2.5. Orchestrator#

Bisher haben Sie viele verschiedene Komponenten kennengelernt, und es besteht die Notwendigkeit, sie zu koordinieren: die Prozesse der verschiedenen Bausteine zu integrieren und anspruchsvolle End-to-End-Automatisierungs-Workflows zu erstellen. Deshalb muss der Orchestrator mehrere Interaktionsmöglichkeiten unterstützen, vom manuellen Auslösen bis hin zu vollständig ereignisgesteuerten Workflows, sowohl synchron als auch asynchron.

Die Workflows, die der Orchestrator implementiert, sollten Möglichkeiten zur Definition mehrerer Schritte bieten und müssen auch Rollback- und Dry-Run-Funktionen unterstützen, wobei er auf die anderen Komponenten angewiesen ist (z.B. versionierte Snapshots aus dem Intent-Block).

Im manuellen Betrieb ist dies normalerweise lose in einer Checkliste für einen Prozess definiert, der befolgt werden muss.

Diese Komponente bietet Benutzern eine umfassende Visualisierung dessen, was in der gesamten Netzwerkautomatisierung vor sich geht, und zeigt durch klares Logging und Nachverfolgbarkeit, wie die verschiedenen Prozesse zusammenkommen.

Beispiele hierfür sind AAP oder AWX (Ansible Automation Platform), Windmill oder Prefect.

Wo KI und Agenten in die Architektur passen: KI-gestützte Entscheidungsfindung sitzt hauptsächlich an der Schnittstelle der Orchestrator- und Observability-Blöcke. Ein KI-Agent folgt einer Sense-Logic-Act-Schleife: Er beobachtet den Netzwerkzustand durch den Observability-Block, wendet Logik an, um zu entscheiden, welche Aktion benötigt wird, und löst den Executor über den Orchestrator aus. Das unterscheidet sich von der traditionellen Rolle des Orchestrators (einem vordefinierten Workflow folgen), nutzt aber dieselbe Infrastruktur. Kapitel 7 (Orchestrierung, Abschnitt 7.2.7) behandelt den agentischen Ansatz als Koordinationsmuster; Kapitel 15-17 erkunden ihn als Grundlage für autonome Netzwerke. Für jetzt sollten Sie agentische Automatisierung als einen Koordinationsansatz betrachten, der statische Workflow-Definitionen durch dynamische, modellgetriebene Entscheidungsfindung ersetzt.

Tauchen Sie in Kapitel 7 ein, um mehr über Workflow-Design, ereignisgesteuerte Automatisierung und Orchestrierungsplattformen zu erfahren.

3.2.6. Presentation#

Manchmal vergessen wir, wie wichtig es ist, die richtige Schnittstelle für die Benutzer der Netzwerkautomatisierung bereitzustellen. Dies ist normalerweise ein unscharfer Bereich, weil alle Tools, die wir bereits vorgestellt haben, eine Art Schnittstelle haben: CLI, API oder webbasiert. In einigen Fällen können Sie entscheiden, dass das ausreicht. In anderen Fällen könnten Sie Ihre eigene Benutzeroberfläche erstellen, um das Beste aus allen Welten zu holen und die Benutzererfahrung zu vereinfachen. Es kommt darauf an.

Traditionell war dies für externe Benutzer auf Telefonanrufe oder E-Mails beschränkt, und für Netzwerkteams auf CLI.

Auf die eine oder andere Weise muss diese Schicht flexible Authentifizierung und Autorisierung ermöglichen (sie ist der Einstiegspunkt Ihres Systems) und sich dann den tatsächlichen Bedürfnissen anpassen. Manchmal könnte das eine netzwerkspezifische Plattform sein, manchmal könnte sie sich mit unternehmensweiten Systemen integrieren (ServiceNow, Slack usw.).

Je nach Rolle könnte sie Schreib- oder Leseoperationen abdecken, aber berücksichtigen Sie immer die Bedürfnisse Ihrer verschiedenen Benutzertypen für die besten Ergebnisse.

Erkunden Sie Benutzererfahrung, Schnittstellendesign und Integrationsmuster in Kapitel 8.

3.2.7. Das Netzwerk#

Zuletzt, aber nicht weniger wichtig, müssen wir die Fähigkeiten des Netzwerks verstehen, Automatisierung zu unterstützen, und das Netzwerk besteht nicht mehr nur aus Geräten und verbundenen Kabeln. In den 2020er Jahren machen Virtualisierungs- und cloudbasierte Netzwerklösungen die End-to-End-Erreichbarkeit (das Netzwerk) zu einer hybriden und vielfältigen Umgebung.

Das Netzwerk selbst ist sowohl eine Einschränkung als auch ein Enabler für Ihre gesamte Automatisierungsarchitektur. Im Gegensatz zu den vorherigen sechs Blöcken, über die Sie Kontrolle haben, kann die Netzwerkinfrastruktur (Ihre Geräte, Plattformen, Dienste und Konnektivität) Einschränkungen haben, die beeinflussen, was möglich ist.

Netzwerkfähigkeiten fallen in mehrere Kategorien:

• Schnittstellen und Protokolle: Welche Verwaltungsschnittstellen unterstützt Ihr Netzwerk? SSH-CLI? NETCONF? gNMI? REST-APIs? SNMP? Einige Plattformen unterstützen viele, andere wenige. Diese Entscheidungen schränken direkt ein, was Collector und Executor tun können.
• Datenmodelle: Selbst wenn ein Gerät gNMI unterstützt, können die YANG-Modelle, die es bereitstellt, unvollständig sein. Zum Beispiel könnte Ihr Gerät gNMI-Unterstützung behaupten, aber nicht die spezifische Konfiguration offenlegen, die Sie verwalten müssen. Das Verstehen dieser Lücken ist bei der Planung entscheidend.
• Betriebsreife: Neuere Plattformen können moderne APIs haben, aber undokumentiertes Verhalten. Ältere Plattformen können stabil sein, aber überhaupt keine APIs haben. Sie müssen die tatsächliche Reife bewerten, nicht nur die beworbenen Funktionen.

Um Automatisierung effektiv zu unterstützen, sollte Ihre Netzwerkinfrastruktur idealerweise Folgendes bieten:

• Entwicklungs- und Testumgebungen: Wie die Softwareentwicklung erfordert Automatisierung sichere Testorte. Das könnte bedeuten: Lab-Netzwerke (oft teuer und begrenzt), virtuelle Netzwerkumgebungen (Containerlab, GNS3) oder herstellerbereitgestellte Simulatoren (Cisco DevNet, Arista EOS-lite).
• Konsistente Schnittstellen: Wenn 90% Ihrer Geräte NETCONF unterstützen, aber 10% nur SSH, müssen Sie entweder standardisieren oder mehrere Executors aufbauen. Jede Inkonsistenz erhöht die Komplexität.
• Ausreichende Telemetrie: Wenn Sie die benötigten Daten nicht von Ihren Geräten erhalten können, wird Observability bedeutungslos. Stellen Sie sicher, dass Ihre Geräte Telemetrie (Streaming-Telemetrie, SNMP, Syslog) in der benötigten Granularität und Information streamen können.

Das Netzwerk ist der schwierigste Teil der Architektur zum Ändern. Sie können Ihre Router nicht einfach austauschen. Verstehen Sie also seine Einschränkungen frühzeitig und entwerfen Sie Ihre Automatisierung innerhalb davon. Deshalb verdient der Netzwerk-Block bei der Architekturplanung besondere Aufmerksamkeit.

Verstehen Sie Netzwerkfähigkeiten, Geräte-APIs und Testumgebungen in Kapitel 9.

Als nächstes, um diesen Abschnitt zusammenzufassen, gehen wir einen sehr einfachen Anwendungsfall durch und sehen, wie die Architektur darauf abbildet.

3.2.8. Ein praktisches Beispiel#

Bevor wir in jeden Block eintauchen, lassen Sie uns ein konkretes Szenario durchgehen, das zeigt, wie die Architektur zusammenarbeitet.

Problem: Ein Anwendungsteam hat eine Anfrage für ein neues Anwendungssegment eingereicht: ein neues VLAN, IP-Subnetz, Routing-Richtlinie und Zugangskontrollzone über ein heterogenes Campus-Netzwerk mit etwa 800 Zugangs- und Verteilungs-Switches von Cisco, Arista und HPE. Das Betriebsteam muss es End-to-End erfüllen, ohne manuelle CLI-Arbeit an Hunderten von Geräten.

Wie die Architektur es lösen kann:

1. Intent (Source of Truth): Ein Netzwerkingenieur gibt die neue Servicedefinition in Nautobot ein: VLAN-ID, Subnetz, Routing-Richtlinie, herstellerspezifische Konfigurationstemplates und auf welche Switch-Gruppen es zutrifft. Dies wird als Desired State gespeichert, der einzige Ort der Wahrheit für 800 Geräte.
2. Orchestrator: AWX empfängt einen Webhook von Nautobot über die Änderung und löst den Ausführungs-Workflow aus, der die Schritte in der richtigen Reihenfolge koordiniert und Ausfälle pro Gerät behandelt.
3. Executor: Ein Ansible-Playbook liest aus der Nautobot-Application Programming Interface (API), rendert gerätespezifische Konfigurationen pro Hersteller (Cisco, Arista und HPE erfordern jeweils unterschiedliche Syntax) und überträgt Änderungen via NETCONF. Jede Ausführung ist idempotent: Das erneute Ausführen auf bereits konfigurierten Switches bewirkt keine Änderung.
4. Collector: Nach dem Deployment verbindet sich ein gNMIc-Collector mit jedem Switch und ruft tatsächliche VLAN-Mitgliedschaft, Interface-Zustand und Routing-Einträge ab.
5. Observability: Die gesammelten Daten fließen in eine Prometheus-Time Series Database (TSDB). Eine Abfrage vergleicht Desired State (aus Intent) mit Actual State (aus Collector). Switches, bei denen das VLAN fehlt, werden als Metriken angezeigt und lösen Alerts aus.
6. Orchestrator: Wenn ein Alert ausgelöst wird (“VLAN 210 nicht vorhanden auf access-switch-b3-07”), führt ein AWX-Workflow automatisch den Executor auf diesem Switch erneut aus, sammelt Daten neu und validiert die Behebung.
7. Presentation (Layer): Ein Dashboard zeigt alle 800 Switches nach Gebäude und Hersteller gruppiert und hebt hervor, welche konform sind (✅) und welche abgedriftet sind (❌). Das Anwendungsteam kann den Rollout ohne CLI-Zugang verfolgen. IT-Betrieb kann manuelle Behebungen auslösen, ohne Code zu schreiben.
8. Das Netzwerk: Der Erfolg dieses Ablaufs hängt davon ab, was die Geräte tatsächlich unterstützen. Bei Cisco und Arista funktioniert NETCONF einwandfrei. Mehrere HPE-Switches unterstützen nur SSH-CLI, daher übernimmt ein separater Executor-Pfad diese - weniger elegant, aber notwendig. Keine Architektur beseitigt Herstellereinschränkungen; sie macht sie nur explizit.

Die Kernerkenntnis: Kein einzelnes Tool hat das getan. Nautobot (Intent), Ansible (Executor), gNMIc (Collector), Prometheus (Observability), AWX (Orchestrator) und ein Grafana-Dashboard (Presentation) haben alle zusammengearbeitet. Die Architektur lieferte das mentale Modell für deren Integration.

Das ist, was architektonisches Denken ermöglicht: systematische, komposierbare Automatisierung.

In Teil 2 (Kapitel 4-9) kehren wir zu diesem Campus-Netzwerk zurück, um jeden Baustein eingehend zu erkunden: Die SoT speichert die VLAN-Servicedefinition (Kapitel 4), der Executor stellt sie bereit (Kapitel 5), Observability überwacht sie (Kapitel 6), der Orchestrator koordiniert den gesamten Lebenszyklus (Kapitel 7), die Presentation-Schicht stellt sie verschiedenen Zielgruppen bereit (Kapitel 8), und das Netzwerk-Kapitel schließt mit einem simulationsbasierten Vorproduktions-Gate (Kapitel 9). Wo Beispiele auf ein Source-of-Truth-Tool verweisen, werden Nautobot und NetBox austauschbar verwendet; die architektonischen Muster sind unabhängig von der gewählten Lösung dieselben.

3.3. Wie man eine Architektur nutzt#

Da Sie nun die verschiedenen Bausteine der NAF-Netzwerkautomatisierungsarchitektur verstehen, fragen Sie sich vielleicht: “Wie fange ich in meinen Projekten damit tatsächlich an?”

3.3.1. Sequenzieller Ansatz zur Einführung#

Die Referenzarchitektur ist keine Vorschrift. Es ist ein Rahmen zum Nachdenken über und Organisieren von Automatisierungslösungen. Hier ist ein praktischer, sequenzieller Ansatz zur Anwendung:

flowchart LR
    A[Ist-Zustand verstehen]:::phase1 --> B[Automatisierungsweg planen]:::phase2
    B --> C[Bessere Tool- & Designentscheidungen treffen]:::phase3
    C --> D[Für Integration entwerfen]:::phase4
    D --> E[Mit Stakeholdern kommunizieren]:::phase5
    E --> F[Inkrementell weiterentwickeln]:::phase6

    classDef phase1 fill:#e0f7fa,stroke:#333,stroke-width:2px;
    classDef phase2 fill:#b2ebf2,stroke:#333,stroke-width:2px;
    classDef phase3 fill:#80deea,stroke:#333,stroke-width:2px;
    classDef phase4 fill:#4dd0e1,stroke:#333,stroke-width:2px;
    classDef phase5 fill:#26c6da,stroke:#333,stroke-width:2px;
    classDef phase6 fill:#00bcd4,stroke:#333,stroke-width:2px;

Phase 1: Ist-Zustand verstehen

Beginnen Sie damit, Ihre vorhandenen Tools und Prozesse den architektonischen Blöcken zuzuordnen. Diese Bewertungsübung hilft Ihnen, Lücken, Überlappungen und potenzielle Verbesserungsbereiche zu identifizieren:

• Sind Ihre Daten über mehrere Systeme verteilt?
• Sammeln Sie den Netzwerkzustand effektiv, oder fliegen Sie blind?
• Wie führen Sie derzeit Änderungen durch? Manuell? Ad-hoc-Skripte? Organisierte Frameworks?

Wenn Sie hervorragende Ausführungsfähigkeiten, aber schlechte Observability feststellen, haben Sie ein Problem mit hohem Einfluss identifiziert, das Sie als nächstes lösen sollten.

Phase 2: Automatisierungsweg planen

Nutzen Sie die Architektur, um Ihre Automatisierungs-Roadmap zu leiten. Sie müssen nicht alle Blöcke auf einmal implementieren. Beginnen Sie mit Komponenten, die Ihre kritischsten Schmerzpunkte angehen:

• Wenn Sie mit Konfigurationsdrift zu kämpfen haben, konzentrieren Sie sich auf Intent/Source of Truth und Execution.
• Wenn Sie Probleme nicht schnell erkennen können, priorisieren Sie Collector und Observability.
• Wenn Ihre Automatisierung fragmentiert und unzuverlässig ist, investieren Sie in Orchestrierung.
• Wenn Benutzer verwirrt sind, wie sie Änderungen anfordern sollen, verbessern Sie Presentation.

Priorisieren Sie nach Geschäftsauswirkung, nicht nach architektonischer Vollständigkeit.

Phase 3: Bessere Tool- und Designentscheidungen treffen

Bei der Bewertung neuer Tools oder dem Erstellen benutzerdefinierter Lösungen fragen Sie sich:

• Welchem architektonischen Block dient das?
• Integriert es sich gut mit meinen anderen Komponenten?
• Welche Datenflüsse benötige ich zwischen Blöcken?

Das verhindert Tool-Proliferation und stellt sicher, dass Ihr Automatisierungs-Ökosystem kohäsiv bleibt. Es klärt auch, ob Sie kaufen oder bauen sollten. Wenn ein Tool sauber in einen Block passt und klar definierte Schnittstellen hat, ist es normalerweise besser zu kaufen als zu bauen.

Phase 4: Für Integration entwerfen

Das Verstehen der Grenzen zwischen Komponenten hilft Ihnen, bessere Schnittstellen zu entwerfen. Schlüsselprinzip: Komponenten müssen die internen Abläufe der anderen nicht kennen.

• Ihr Executor muss nicht wissen, wie Intent Daten speichert: Er braucht nur eine klar definierte API, um den gewünschten Zustand abzufragen.
• Ihr Orchestrator sollte sich nicht darum kümmern, ob Sie Ansible oder Terraform verwenden: Er löst nur die Ausführung aus und überwacht Ergebnisse.
• Ihr Observability-System muss die internen Abläufe des Collectors nicht kennen: Es braucht nur klare Metriken und Ereignisse.

Diese Entkopplung ist das, was es Ihnen ermöglicht, jede Komponente unabhängig weiterzuentwickeln.

Phase 5: Mit Stakeholdern kommunizieren

Die Architektur bietet eine gemeinsame Sprache für die Diskussion von Automatisierung mit verschiedenen Zielgruppen:

• Zur Unternehmensführung: “Wir stärken unsere Observability-Position, um die MTTR zu reduzieren.”
• Zu Ihrem Team: “Lass uns standardisieren, wie unser Collector Daten an Observability sendet.”
• Zu anderen Abteilungen: “Unsere Presentation-Schicht wird sich mit Ihrer ITSM-Instanz integrieren.”

Klare architektonische Sprache reduziert Verwirrung und hilft, Zustimmung zu sichern.

Phase 6: Inkrementell weiterentwickeln

Die Architektur ermöglicht es Ihnen, Komponenten auszutauschen, wenn sich Ihre Bedürfnisse ändern:

• Heute könnten Sie Git als Ihre Source of Truth verwenden, aber morgen könnten Sie NetBox oder Infrahub einführen, ohne Ihre Automatisierungs-Workflows vollständig neu zu gestalten, solange Sie klare Schnittstellen beibehalten.
• Sie könnten mit einem einfachen Skript als Orchestrator beginnen und ihn später durch AAP oder Windmill ersetzen.
• Sie können von einer TSDB zu einer anderen in Observability migrieren, ohne zu stören, wie Collector seine Daten abruft.

Dieser evolutionäre Ansatz minimiert Risiken und ermöglicht es Ihnen, unterwegs zu lernen.

Tappen Sie nicht in die Falle des Überengineerings. Das Ziel ist keine architektonische Reinheit, sondern praktische Automatisierung, die echte Probleme löst. Manchmal ist die beste Lösung ein einfaches Skript, das mehrere architektonische Blöcke umspannt. Die Architektur ist ein Leitfaden, keine Zwangsjacke.

Die wichtigste Erkenntnis: Nutzen Sie die Architektur als mentales Modell, um Ihr Denken zu organisieren, Lücken zu identifizieren und bewusste Designentscheidungen zu treffen. Nicht als starre Vorlage, die jedes Implementierungsdetail vorschreibt.

3.3.2. Häufige Fallstricke vermeiden#

Seien wir ehrlich: Sie werden Fehler machen. Aber von anderen zu lernen kann Ihnen eine Menge Schmerz ersparen. Hier sind häufige Fallstricke:

1. Versuchen, alles auf einmal zu implementieren

   Es ist verlockend zu denken: “Wenn diese Architektur gut ist, sollte ich alle sieben Blöcke perfekt aufbauen.” Das führt zu massiven, mehrjährigen Projekten, die veraltet sind, bevor sie fertig sind.

   Besserer Ansatz: Beginnen Sie mit einem oder zwei Blöcken, die Ihr dringlichstes Problem lösen. Inkrementell aufbauen. Frühe Erfolge schaffen Dynamik und Zustimmung.

2. Glauben an “Ein Tool, sie alle zu beherrschen”

   Einige Hersteller behaupten, ihre Plattform tue alles. Das mag zwar stimmen, bedeutet aber oft:

   • Sie sind an ihre Art, Dinge zu tun, gebunden.
   • Sie können Komponenten später nicht austauschen.
   • Sie zahlen für Funktionen, die Sie nicht benötigen.

   Besserer Ansatz: Best-of-breed-Tools für jeden Block wählen, aber sicherstellen, dass sie klare APIs und Integrationspunkte haben. Akzeptieren, dass Sie möglicherweise 3-5 Tools integrieren müssen, aber Sie werden Flexibilität haben.

3. Netzwerkeinschränkungen ignorieren

   Sie entwerfen einen eleganten Executor mit gNMI, aber 30% Ihrer Geräte unterstützen nur SSH-CLI. Oder Sie möchten Streaming-Telemetrie, aber Ihre älteren Plattformen unterstützen nur SNMP.

   Besserer Ansatz: Verstehen Sie zunächst die Fähigkeiten Ihrer Netzwerkinfrastruktur. Diese Einschränkungen formen Ihre Architektur. Sie können Physik nicht ignorieren, und Sie können nicht ignorieren, was Ihre Geräte tatsächlich leisten können.

4. Annehmen, Schnittstellen werden einfach sein

   Sie sagen: “Executor wird einfach die API von Intent für den gewünschten Zustand aufrufen.” Aber Intent verwendet NetBox mit benutzerdefinierten Erweiterungen, und Executor erwartet flaches YAML. Plötzlich schreiben Sie Übersetzungsschichten.

   Besserer Ansatz: Im Voraus in klare, gut dokumentierte Schnittstellen investieren. Standards verwenden, wo möglich (REST-APIs, gRPC, klare Schema-Definitionen). Gute Schnittstellen kosten jetzt weniger als Übersetzungsschichten später.

5. Benutzerdefinierte Tools bauen, wenn gute existieren

   Ihr Team entscheidet sich, einen benutzerdefinierten Collector zu bauen, weil “kein Tool genau unseren Bedürfnissen entspricht”. Sechs Monate später haben Sie 3.000 Zeilen Code, die proprietäre Telemetrie-Pipelines verwalten.

   Besserer Ansatz: Vorhandene Tools zuerst bewerten (Telegraf, Vector, gNMIc). Sie decken 80% der Anwendungsfälle ab und sind kampferprobt. Anpassen oder Adapter bauen, wenn nötig, aber nicht von Grund auf neu bauen.

6. Observability als nachträglichen Gedanken behandeln

   Viele Teams konzentrieren sich auf Intent und Executor und erkennen dann zu spät, dass sie nicht sehen können, was im Netzwerk tatsächlich passiert. Observability wird zuletzt angebaut.

   Besserer Ansatz: Observability von Tag eins an planen. Welche Metriken werden Sie sammeln? Wie werden Sie Drift erkennen? Welche Alerts sind wichtig? Diese Fragen beantworten, bevor Sie den Executor bauen.

7. Benutzer vergessen

   Ingenieure bauen einen leistungsstarken Orchestrator, aber die einzige Möglichkeit für Benutzer, damit zu interagieren, sind CLI-Befehle. Nicht-technische Benutzer werden verwirrt; die Einführung ist schlecht.

   Besserer Ansatz: Früh über Ihre Benutzer nachdenken. Welche Schnittstellen benötigen sie? APIs? Web-UI? ServiceNow-Integration? Manchmal entscheidet die Presentation-Schicht über Erfolg oder Misserfolg der Einführung.

Diese Fallstricke sind nicht theoretisch - sie sind Muster aus echten Automatisierungsprojekten. Jetzt davon zu lernen wird Ihre Architektur stärker machen.

3.3.3. Wo anfangen#

Die Architektur definiert sieben Blöcke. Niemand implementiert alle sieben auf einmal. In der Praxis machen zwei Startmuster die Mehrheit realer Deployments aus.

Muster A: Konfigurationsgesteuerter Start (am häufigsten)

Teams, die Konfigurationen bereits manuell verwalten und diesen Prozess konsistent und automatisiert machen wollen. Beginnen mit Intent und Executor: eine Source of Truth einrichten und die Playbooks zum Deployment daraus aufbauen. Observability hinzufügen, sobald die Ausführung stabil ist und Sie Feedback brauchen, was tatsächlich deployed wurde.

flowchart LR
    A[Intent / SoT] --> B[Executor] --> C[Observability] --> D[Orchestrator] --> E[Presentation]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

Muster B: Transparenzgesteuerter Start

Teams, deren Hauptproblem darin besteht, den aktuellen Zustand des Netzwerks nicht zu kennen. Beginnen mit Collector und Observability: zuerst die Datenpipeline aufbauen, verstehen, was tatsächlich deployed ist, dann Intent und Executor hinzufügen, sobald ein zuverlässiges Bild für das Deployment vorliegt.

flowchart LR
    A[Collector] --> B[Observability] --> C[Intent / SoT] --> D[Executor] --> E[Orchestrator]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

In beiden Mustern kommen Orchestrator und Presentation, nachdem die Kerndatenflüsse stabil sind. Mit dem Orchestrator zu beginnen, bevor zuverlässiger Intent oder Ausführung vorhanden ist, ist verfrüht: Es gibt noch nichts Bedeutungsvolles zu koordinieren. Presentation wird wichtig, sobald interne Teams die Automatisierung nutzen und eine ordentliche Schnittstelle statt direktem API- oder CLI-Zugang benötigen.

Das sind Ausgangspunkte, keine Blueprints. Ihre Einschränkungen (vorhandene Tools, Team-Fähigkeiten, der dringendste Schmerzpunkt) sollten die Reihenfolge bestimmen. Der Schlüssel ist, einen Ausgangspunkt bewusst zu wählen statt zu versuchen, alles parallel zu bauen und nichts zu beenden.

3.3.4. Blöcke teamübergreifend verwalten#

Sieben Blöcke stellen eine organisatorische Frage genauso wie eine architektonische: Wer besitzt was, und wie können mehrere Teams dieselbe Plattform nutzen, ohne sich gegenseitig zu behindern?

Das häufigste Modell in mittleren und großen Organisationen teilt sich in zwei Gruppen auf. Ein Plattform-Team besitzt die Automatisierungsinfrastruktur selbst: das SoT-Schema und die APIs, den Orchestrator-Laufzeit, die Observability-Pipeline, die Presentation-Schicht und die gemeinsame Collector-Infrastruktur. Das sind die Komponenten, von denen der Rest der Organisation abhängt. Die Aufgabe des Plattform-Teams ist es, sie zuverlässig, versioniert und verfügbar zu halten. Ein Netzwerkbetriebsteam (oder mehrere Domänenteams, eines pro Technologiebereich) besitzt den Automatisierungs-Inhalt: die Playbooks, Workflow-Definitionen, vorgesehenen Daten und Geschäftslogik, die auf der Plattform laufen. Sie konsumieren die Plattform; sie warten sie nicht.

Diese Aufteilung hat Auswirkungen darauf, wie Blockgrenzen in Teamgrenzen übersetzt werden. Die SoT ist eine gemeinsame Plattformressource, aber verschiedene Teams haben unterschiedliche Schreibrechte dafür: Das IP-Adressierungsteam kann die IPAM-Daten besitzen; das Campus-Team kann das Switch-Inventar besitzen; das Sicherheitsteam kann die Firewall-Richtliniendaten besitzen. Das Term "rbac" not found-Modell der SoT muss diesen Eigentumsgrenzen entsprechen. Ein Schreiben in die falsche Domäne ist ein operationeller Vorfall, der darauf wartet zu passieren.

Der Orchestrator ist ähnlich: Das Plattform-Team besitzt den Laufzeit und das Workflow-Ausführungsframework; das Betriebsteam besitzt die Workflow-Definitionen. Workflow-Definitionen sollten unter der Eigentümerschaft des Betriebsteams in der Versionskontrolle leben, vom Orchestrator zum Deployment-Zeitpunkt abgerufen, anstatt direkt in der UI des Orchestrators bearbeitet zu werden. Das hält Plattform-Team und Betriebsteam davon ab, sich gegenseitig in die Quere zu kommen.

Presentation unterteilt die Eigentumsfrage weiter. Eine interne API, die von anderen Automatisierungstools verwendet wird, ist ein Plattformanliegen. Ein Self-Service-Portal für Anwendungsteams ist ein Produktanliegen, das möglicherweise einem dedizierten Tool-Team oder einer Shared-Services-Gruppe gehört. Das frühzeitige Definieren dieser Grenzen verhindert die Situation, in der jedes Team seine eigene Ad-hoc-Schnittstelle zur selben zugrunde liegenden Plattform aufbaut.

Die organisatorische Dimension des Betriebs einer Automatisierungsplattform, einschließlich wie Teams sich darum strukturieren, wie Produktdenken auf interne Tools angewendet wird und wie Plattform-Teams den Vertrag mit ihren internen Konsumenten verwalten, wird ausführlich in Kapitel 10 (Platform Engineering) und Kapitel 13 (Kultur und Zusammenarbeit) behandelt. Die hier getroffenen architektonischen Entscheidungen, insbesondere SoT-RBAC-Bereich und Orchestrator-Workflow-Eigentümerschaft, schränken direkt die organisatorischen Modelle ein, die diese Kapitel beschreiben.

3.4. Zusammenfassung#

Architektonisches Denken ist wesentlich für den Aufbau von Netzwerkautomatisierung, die tatsächlich funktioniert. So wie das OSI-Modell uns einen geschichteten Rahmen zum Verständnis von Netzwerken gibt, hilft eine Referenzarchitektur Ihnen, Automatisierungssysteme zu organisieren und zu entwerfen, die wartbar, skalierbar und zuverlässig sind.

Dieses Kapitel hat das NAF Framework vorgestellt, das sieben wichtige Bausteine definiert. Die Architektur ist keine starre Vorschrift - sie ist ein flexibler Rahmen. Nutzen Sie ihn, um Ihren aktuellen Zustand zu bewerten, Ihren Automatisierungsweg zu planen, fundierte Tool-Entscheidungen zu treffen, mit Stakeholdern zu kommunizieren, für Integration zu entwerfen und inkrementell weiterzuentwickeln. Denken Sie daran: Das Ziel ist praktische Automatisierung, die echte Probleme löst, keine architektonische Reinheit.

In Teil 2 dieses Buches werden wir tief in jeden dieser Bausteine eintauchen und Implementierungsmuster, Best Practices und reale Beispiele erkunden, die Sie auf Ihre eigenen Automatisierungsprojekte anwenden können.

💬 Found something to improve? Send feedback for this chapter