Why automation scripts are just a stepping stone in your automation endeavours

The migration from CLI based network management has long started and the benefits from the shiny new world of network automation are pouring in. But not everything that glitters is gold. In this post I tell you about my experience, the problems I found and where network automation has taken us.

On the road towards the brave new world, network engineers learn to code and automate tasks. Changes that might have taken days to weeks to perform can now be executed in minutes… once a cool script has been written. Solving problems with scripting is very flexible, fast developed and it’s easier than ever to archive standardisation across the configuration.

Like many other engineers I was extensively using Ansible and plain python scripts. This has often proven to be a fruitful approach, especially for one-off changes. At the same time I came across the same issues over and over again:

• Repeatedly investing a lot of time in basics like argument parsing, connection and error handling (fire and forget) for every script frustrated me.
• Executing a script written by someone else always triggered a feeling of discomfort not knowing what’s happening (without reverse engineering).
• Because scripts are only executed and expanded by the people who developed them, there is no collaboration within the team nor with other teams. Therefore other employees cannot develop their own skills and you will always end up with the same few people you depend on (and they are of course always overloaded).

With more than 10 years experience as a network engineer I was tired of these problems stopping me from focussing on my key work, network design.

When I started working at zebbra AG a few years ago, I found like minded people that have already experienced similar situations. Zebbra isn’t just strong in network automation but also in building full fledged software solutions, an optimal breeding ground for building the network engineers dream solution. An interdisciplinary core team was formed, which started to work on the vision of simplified network automation.

Vision

Our main goals:

• Let the network engineers focus on the design of automation tasks by providing an ecosystem that handles the heavy lifting (task execution, data gathering, error handling, …)
• Provide visibility and traceability across the whole stack (instead of click and pray)
• Make delegating automation tasks worry-free
  Not only your team but also your colleagues from the ops team, the fieldforce or even the customer himself can execute predefined tasks
• Integrate with other systems to provide digitalised E2E processes
• Fully support new and legacy infrastructure/equipment/data source

While we initially only wanted to make network automation easier for ourselves, we started to realise that there was unprecedented value in the ecosystem we wanted to build. Not only did it make it easier and way faster for network engineers to build their automation, but the level of visibility allowed people to truly collaborate on automation endeavours.

By means of abstraction and providing a user friendly interface, collaboration didn’t stop at an engineering level but allowed us to onboard other teams as well.

The magic behind the curtain and how it all began

On a day about a year ago, I received the order to rename network elements due to structural changes. A simple job that can be easily automated. But an important point was that the task had to be synchronized with the business process and renamed location by location, department by department.

Since I don’t like to be involved in organizational processes and knew that my colleagues don’t like to execute my scripts, it was clear to me that the task must be parameterizable and executable over a frontend. Everyone involved in the process should be able to do the work for a given location.

From the perspective of the task it was clear that an old name and a new name for a department are needed. But how do you bring this information into the frontend? We used a schema definition rendered from the frontend, so the network engineer creating the automation task does not have to care about the frontend and does not have to learn JavaScript.

When all migrations were done by my colleagues, there were situations where elements were described incorrectly before the change due to fat fingers. Unfortunately, the billing is related to these names, interesting for the customer, but not for us.

Like other solutions, we rely on facts collected from the network. The rename task saved all descriptions as facts to the network elements, based on that we changed the matching elements. When incorrect names appeared, we were able to filter out all incorrect elements with searches based on facts, adjust our automation tasks accordingly or trigger manual changes.

The task was done, everyone was happy, we saved a lot of time, because we were able to react to the circumstances and we were able to delegate tasks to people with an appropriate know-how.

To be honest, as huge open source fans, we didn’t build our solution from scratch. Even our stack outsources the heavy lifting to underlying libraries and frameworks like django, nornir, netmiko, ncclient, elastic stack, vue.js and many more.

Conclusion

Writing scripts is just the beginning of the network automation journey. Once you master these skills, your colleagues sooner or later want to get in on the action. So you need to be able to share your work and give everybody the same view of what the current state is, what has changed or where failures have been detected during provisioning.

To build custom network logic you need to be able to integrate data from other systems like an ITSM or an IPAM. There’s no way around APIs, Data Management, a scalable architecture and maybe even a nice UI for less technical people. Well, soon you’ll end up building a huge platform and the more critical it will get, the more you will find yourself tied up in maintenance work.

Building such a platform is really fun, but it’s certainly not everybody’s cake and the effort, experience and development skills needed are tremendous. Therefore we leveled up and polished our framework and offer it as the product neops.io. Curious?

Take Action

Mastering network automation is like Kung Fu. You don’t become a master overnight. It needs years of training, room for failure and peers from whom you can learn. The important thing is that you are starting or keep moving on this journey!

That said, neops.io isn’t a silver bullet and you will still need to practice your coding & network design skills. But, it will provide you with a turbo booster to reach new maturity and complexity levels of automation.

Our approach is certainly not the only solution and we are always happy to hear from you what you think about this topic or what problems are keeping you awake at night.

If you like to know more about neops.io, I’m more than happy to personally give you a practical demo and talk about your use-cases! For more technical information you can have a sneak-peek at docs.neops.io.

Btw, if you would like to hear a first hand report how neops.io made my colleague Roland Mamie (CCIE) life a lot more joyful, read more about his experience here.

‍