I was at the London Network Automation meetup this past week. London has a great community of network engineers that are eager to improve their current skill set and make their work lives easier. This meetup was geared towards learning new technologies around automation in the networking industry. There were talks about new ways to implement various existing automation tools, as well as real world discussions around how automation was implemented in the industry.
One common theme I experienced was how eager all network engineers are to open the scripts and code they write to administer their network devices. The sense of community and camaraderie amongst peers in this industry is one of the reasons I really enjoy working in this field. This is a real change in the industry. Even one year ago, the majority of network engineers did not have accounts on github or gitlab. Now, all these same network engineers exchange github and gitlab accounts like business cards. I couldn’t be happier with the direction this industry has taken.
However, I also couldn’t help but think about the irony of this situation. These creative and intelligent engineers are creating innovative scripts to shoehorn solutions into closed systems. Then, the community demands that these scripts be open sourced. The irony is that this community doesn’t put the same pressure on the end vendors to open their code, even though the vendors are the ones providing the networking operating systems.
Naturally, I’ll approach these engineers and tell them about Cumulus Linux — an open networking operating system that better integrates with open source automation solutions and shares the same concepts. Some engineers are excited to hear about this new paradigm, and we dive deeply into how well Cumulus Linux integrates with automating tooling. Occasionally, we get the engineers that want to leverage automation and believe in shared open scripts for operations, but are still beholden to the closed operating system world of Cisco, Arista and Juniper.
These conversations give me grave concern. The unwillingness to look at the system holistically, and the desire to treat their networks as bolt-on solutions, is unfortunate. The power of automation can only fully be leveraged when the targets of your automation systems are receptive to native automation tooling integration without the need for proprietary middleware.
Going back to the events at the London Network Automation meetup, the session had three great presenters, all of whom discussed automation solutions they had implemented to provide greater insights into their network infrastructure, or make their work more productive and interesting. The most intriguing presenter was the final one, Paul Prisecar, who delivered the My Project portion of the meetup. Paul developed a script to automatically provision small business routers that needed to be delivered on-site to various world-wide stores. He had to write an extensive amount of code to interact with the closed operating system to do something as simple as ZTP functions on Cumulus Linux. Paul created a little program that helped him save lots of time, but it wasn’t without the inherent automation-deficient nature of these closed operating systems.
At the end of the presentations, there was a panel Q&A session. The audience asked the panelists about what they believe is the biggest barrier to entry for new network automation efforts. Common themes were the time investment required to develop the automation skills and getting manager buy-in to implement automation tooling. I agree with these two reasons, but they are not the biggest barriers to entry. The true barrier to entry is a free, easily accessible, simple-to-use simulation infrastructure that can be leveraged as a sandbox to learn and demonstrate automation tooling.
Simple, easy and free tooling create san efficient environment to study and learn automation. It will eliminate the barriers perceived in the “management buy-in” and “time investment to learn.” The solution to these two problems is an easy platform that demonstrates value and reduces time to expert. When I speak to customers about automation, I always follow with how accessible Cumulus In The Cloud (and Cumulus VX for more tech savvy individuals) and our open source tooling infrastructure are. I highlight how these tools can be used for implementing a full replica of your production network environment, and for learning about how automation can be leveraged to improve day-to-day operations. And since it is a simulation, demonstrating the benefits to stakeholders becomes very easy.
If you’re feeling adventurous and tech savvy, you can follow our docs to install Vagrant, Libvirt and KVM/QEMU to create your own simulation server. With that environment, you can use Cumulus VX to emulate your network infrastructures and learn how to properly automate, without the requirement of middleware NOS APIs to interpret automation tooling.