We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

This is the way - Holistic (Network) Automation

Formale Metadaten

Titel
This is the way - Holistic (Network) Automation
Serientitel
Anzahl der Teile
62
Autor
Lizenz
CC-Namensnennung 4.0 International:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
The Systems Engineering / SRE world has undergone a shift of thinking towards intend driven holistic configuration management a long time ago, but it feels like the majority of network automation solutions are still following the idea of making incremental changes to the routers and switches out there, which at the same time might also be managed manually by operators typing (or copying) magic spells into a CLI. This makes the device configuration the synchronization point and we don’t really have an idea of what this configuration will look like in full without checking back on the device. I believe we as Network (Automation) Engineers need to follow suit, make the mental shift to the holistic approach, let Perl, Shell and expect scripts be, and bring software engineering methods to network automation. This way we are able to tackle the problems at hand at an abstract level, build solutions which can be reasoned with, tested on their own, and scale to our needs. For the most daunting problem of configuration management this means plugging some of those systems together and building a solution which generates and owns the full device configuration. Dealing with diverging configuration parts, across the fleet, carefully cleaning up old approaches to configure X, doing incremental changes, and figuring out how to interact with a platform API, a dialect of NETCONF, YANG, etc. would all be from the past –-- wouldn’t that be great?
Schlagwörter