Early on in my automation journey, I learned some basic lessons from experiencing what happens when multiple scripting newbies independently unleash their own notions of automation on the network. I was one of them.
Our earliest automations were largely hacky shell scripts that spat out snippets of config which would then be shoved into routers by other scripts. We’re talking mid 1990s. It started out fun and exciting, but with more vendors, hardware, use cases, issues, and so on, things went sideways.
We ended up with a large pile of scripts with different owners, often doing similar things to the network in different ways. Each script tailored for some narrow task on a specific vendor hardware in a specific role. As folks who wrote the scripts came and went, new scripts of different kinds showed up, while other scripts became orphaned. Other scripts ran in the shadows, only known to their creator. Chasing down script issues was a constant battle. It was quite the zoo.
We learned quickly that with automation power must come automation maturity.
The problem was that we were operating based on the needs at hand, without stepping back and building in the bigger picture. With each need of the day came a new script or tweak to an existing one. Each with different logging, debugging, error handling, etc, if any at all. No common framework. Each script a snowflake more or less. Forbid it that we should make any change to the underlying network design. Eventually the scripts became the new burden in place of those we set out to reduce with them.
Even seasoned developers assigned to network automation make newbie mistake. The code is great, but the automation not so great. Main reason being they lack the subject matter knowledge to deconstruct the network system accurately, and most likely they were not involved when the network was being designed.
IMO, the best network automation comes from a class of networking people that I refer to as network developers — software developers that are networking subject matter experts. These folks understand the importance of the network design being simple to automate. They are core members of the network design team, not outsourced developers.
In my case, I found that if my automation logic reflected the functional building blocks in the network design, I could capture the logic to handle a unique function within corresponding methods of a model-based automation library. For example, a method to generate vendor-specific traffic filter from a vendor-independent model, and another method to bind and unbind it on an interface. Code to handle the traffic filter function was not duplicated elsewhere. Constructing a network service that is a composite of multiple functions was just a matter of creating a service method that invoked the relevant function methods.
This approach ensured that my team focused on systematically enhancing the capabilities of a single automation library rather than replicating the same network manipulations in code over and over in different places. With the devops mindset, often new device features were tested only after incorporating them into the automation library, which meant features were tested with and for automation. Multiple high value outcomes derived from a common coherent automation engine, and a very strong network automation as network design philosophy.
There are certainly other equally good (or better) automation models. For example, Contrail fabric automation takes a role oriented approach.
Let me close before I go too far off on a tangent. The lesson here — don’t wing automation for too long. Aim for method, not madness.
No comments:
Post a Comment