The birth of software defined networks marks the dawn of a new era and with it we see lots of people, teams, and companies talking about “programmability”. I was recently challenged on the benefits of programmability for networks and whether there is benefit or advantage over simply using the CLI.
What I found was that I completely agree there are a lot of current efforts out there to “do programmability” that are failing and not producing results. I also see this as a problem and is one of the reasons that I left Cisco and spent time looking for something new that could take me past the scripts and simple API work I was doing with networking systems.
Many of our clients are doing this automation and programmability with their network engineers. They are leading the charge and have no formal training in CI/CD pipelines, software development methodologies, or have a background in testing code or testing changes to code. These are just some of the cornerstones that enable software to be continuously integrated and deployed. How can we expect to get the same results from an automated network that we do from automated software deployment unless all (or at very least most) of these decade old methodologies are followed?
I believe that the inflection point for network automation is here and passing us by. This inflection point wasn’t even possible until the technology itself was ready and it's finally ready. Puppet, Ansible, Terraform (and many others) all have the ability to control a network. Those tools enabled automation and orchestration of servers to the point where it’s almost becoming ubiquitous with our clients. We laughed at self driving cars, we laughed at landing rocket bodies and reusing them, and we laughed at virtualization. All of those laughable ideas are now possible. Unfortunately many of the existing network engineers are not taking the steps necessary to use these tools appropriately and at the same time I can’t imagine that networking will be the only holdout in the IT world that doesn’t get automated in the next few years. When something this beneficial comes along the industry doesn't go back to the old ways.
While none of this might be relevant to many of our clients I think it’s important that everyone understand that it takes more than the tools to enable automated networks. It takes the coordination of all teams involved, implementation of tried and true methodologies (from the software world as well as networking), and people who are willing to learn and grow. It also takes network engineers who understand networks and networking protocols in depth because they still need to be designed appropriately (the AI for this doesn’t exist yet, but stay tuned).
It’s incumbent on us to be the thought leaders in this space and teach clients how to do these new (to them) things. It’s going to take marketing, persistence, and a willingness to show off every little win so that our clients in the field start to see it working. I think this is no different than the mini demonstrations that are done when an Agile Sprint is completed. It might not be much, but it’s something new, it works, and it shows progress. Those small wins add up to large accomplishments over time. Cisco ACI and SDA are already examples of complete network deployments that can be done without a single line of CLI being entered into a networking device.
I don’t think we are ever going back to a non-automated IT world, so I believe we should lead the way forward. I invite all of us to find a way to make networking easier to manage, faster to provision, and more business enabling than it’s ever been before. If a computer can do it, we should make that happen. It will only benefit us all in the end.
I’ll be at Cisco Live in a few weeks talking a lot about programmability and extensibility, things we at IGNW are working on all the time. Track me down there, or contact us about making your network operate smoothly in an automated programmable manner. We’d love to help.