Network Automation, Programming, And Scale

Networking blogger Greg Ferro wrote an article last year in which he argued that scripting does not scale for network automation. In that article, Greg declared that custom scripting is "pointless in the end" and that "within two years, those scripts will be dead."

Greg's article ultimately poses an interesting question: How do you make your programming scale? Or to put this in different terms, how do you write programs that won't die an untimely death -- that won’t end up in the dustbin of a commented-out crontab?

Now in my view, scripting is a type of programming and programming is the way to achieve network automation. But how do you do this in an enduring way?

Here are some steps that help:

1. Check your code, templates, and configurations into a revision control system.

2. Make your programs readable. Don’t value terseness over readability; don’t value clever programming tricks over comprehension. 

3. Integrate automated testing into your process. Don't rely on manual testing. Write code that tests your code. Write code that tests your changes. You need to know when things aren’t working (and the earlier the better).

4. Don't reinvent the wheel. Use existing libraries and frameworks; search for existing tools that can accomplish the task at hand.

5. Your data structures matter; choose them wisely. Choosing the wrong data structures can cause you a lot of added complexity and unnecessary work.

6. Don't repeat yourself. Don’t copy your code within a given file; don’t copy your code from one file to another. Learn to use the constructs of the language to avoid unnecessary code duplication.

7. Don't repeat yourself.Strive to write code that CAN be reused.

8. Use the right tool for the job. If across an extended period of time, you feel like you are fighting the language, framework, or library, reassess whether you are using the right tool for the job. But…

9. Be wary of bright-shiny-new-thing syndrome.Yes, XYZ looks very interesting, but are the advantages of XYZ worth the time and effort of converting over to it?

Now these technical nuts-and-bolts will get you part of the way there, but are they sufficient for creating an enduring automation system? No, probably not.

There are other non-technical requirements, such as organizational commitment to automation, and having multiple team members that understand, contribute to, and support the system. Additionally, your organization must truly prioritize improvement across time. People say they do, but what does management do and say when things go wrong?

Yes, network automation is a bit of a journey. But hopefully over time you can build something that is valuable and that endures.