Part 1: Rethinking Networking with Automation on Designing Network Automation at Scale

01 - Der Automatisierungsimperativ

Mon, 10 Nov 2025 00:00:00 +0000

1. Der Automatisierungsimperativ#

“Automatisieren oder nicht automatisieren - das ist hier die Frage.”

Seit Software-Defined Networking (SDN) und DevOps aufgetaucht sind, streiten Ingenieure darüber, ob Netzwerkautomatisierung notwendig, ein Luxus oder schlicht Overengineering ist. Die Antwort? Es kommt darauf an. Hyperscaler brauchen sie: Sie haben Anfang der 2010er Jahre damit begonnen, weil sie keine andere Wahl hatten. Kleine Unternehmen benötigen möglicherweise überhaupt keine vollständige Automatisierung. Die meisten Netzwerke liegen irgendwo dazwischen. Kultur, Fähigkeiten, Tool-Reife, Geschäftsprioritäten - all das beeinflusst, wie schnell man die Automatisierung einführt. Heute fügen sich all diese Faktoren zusammen. Automatisierung wird unvermeidlich.

02 - Designprinzipien

Sun, 30 Nov 2025 00:00:00 +0000

2. Designprinzipien#

Ein Netzwerkautomatisierungsteam verbrachte sechs Monate damit, ein System zu entwickeln, auf das es wirklich stolz war. Es bezog Intent aus einem strukturierten Datenmodell, generierte Gerätekonfigurationen durch eine Templating-Engine, validierte Änderungen anhand einer Richtlinienbibliothek und übertrug sie via NETCONF mit vollständiger Rollback-Unterstützung. Architektonisch war es solide. Die Demo für die Unternehmensführung verlief gut. Dann übergaben sie es dem Netzwerkbetriebsteam.

Die Einführung blieb aus. Operatoren nutzten weiterhin die CLI. Auf die Frage nach dem Grund waren die Antworten einheitlich: “Ich weiß nicht, was es tun wird, bevor es es tut.” “Wenn etwas schiefgeht, kann ich nicht erkennen, was passiert ist.” “Ich verstehe nicht, wie man die Ausgabe liest.” Das Automatisierungsteam hatte etwas technisch Beeindruckendes, aber betrieblich Undurchsichtiges gebaut. Es gab keinen Dry-Run-Modus, keine menschenlesbare Änderungsvorschau, keinen Prüfpfad in einer für Operatoren verständlichen Sprache. Das System war eine Black Box, die Vertrauen einforderte, das es sich nicht verdient hatte. Sechs Monate Entwicklungsarbeit blieben ungenutzt.

03 - Architektonisches Denken

Wed, 10 Dec 2025 00:00:00 +0000

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.