The Need for Network Programmability – NetDevOps Series, Part 1

Do you often ask yourself why we keep configuring our network devices in the same way we have been doing it for the last 30 years? Isn’t it strange that we still need to log into each individual box and use command-line instructions to perform any changes? Do you wonder if there might be a more optimal way of configuring your infrastructure, instead of CLI? Does this way of working make you feel like any simple change in your network is too complex to implement? You are not alone!

NetDevOps enables dynamic application development

In this new NetDevOps blog series we will explore alternative and innovative ways of programming your network infrastructure. Yes, when you configure your network devices to adopt a certain behavior, or implement a new available feature, you are programming them. So one of the first things we should be looking for is more optimal ways of programming our infrastructure.

Furthermore, as the network exists to provide connectivity for applications, we should take a look at how these are evolving. You’re hearing a lot about agile, microservices-based, cloud-native development; about DevOps automation with CI/CD pipelines; and automated unit testing. These enable really dynamic application development for quick time-to-market requirements.

Let’s not forget that software is one of the most important assets to differentiate modern enterprises from their competition. Being able to quickly implement new features, deploy new locations, or fix issues, is absolutely key to their success.

Check out our NetDevOps Live page. There’s a new webinar every Tuesday that will help you dig in.

Dynamic applications vs. static network

For years, servers have been virtualized with Virtual Machines that can be automatically deployed in minutes. These days the trend is going to container-based microservices, that are deployed insanely fast. These are short-lived entities that may be deployed dynamically across hybrid cloud environments, interacting among them to provide the desired service with virtually unlimited scalability, and adapting to any possible issues in the underlying infrastructure via declarative statements.

In comparison, network infrastructure is much more static. In order to accommodate requirements from application developers it needs to be faster, more flexible, and cost-optimized. Today, network configuration is often a completely manual process that makes any desired change across the network complex and slow. The more elements these changes include (e.g. firewalls, load-balancers, etc.) the more difficult it gets to make them quick, reliable, and adaptable. This situation often leads to bare minimum configurations in the network, that allows for a faster deployment (e.g. no security ACLs, no QoS config, or trunking every VLAN in an interface) but usually leading to much bigger concerns.

Infrastructure is full of products designed to be used by… well, humans. It may not always seem that way, but human operators are the target users for CLI and web interfaces. This means that when you need to get something done via these interfaces, you (or some other human) has to do the work.

You won’t have to think back too far to remember the last time you needed to complete some bulk-task on a computer. The task probably involved a lot of clicking, typing, copying-and-pasting, or other mind-numbing repetitions. These human interfaces (and the paradigm of having humans do the work) are to blame for the bulk-work that we sometimes have to do to complete a task.

Our brain has a great capacity, but clearly human input/output interfaces with a computer (typing and reading) are not very fast. Our thoughts neck down to this tiny straw, which output-wise is like poking things with your meat sticks, or using words (speaking or tapping things with fingers). For example, machine typing usually happens at a 20th of the speed you are thinking. And I am talking ten-finger typing, let’s not even go into two-finger typing… So while Elon Musk finishes his BMI (Brain Machine Interface), aka Wizard Hat, we will have to explore alternative options that optimize how we configure our networks.

Stay tuned…

In my next post we will explore what programmability actually is and the critical role of coding. See you next week, stay tuned! In the meantime… check out NetDevOps Live.

Any questions or comments please let me know in the comments section below, Twitter or LinkedIn.

Join DevNet to access the learning labs, docs, and sandboxes you need for network automation, application development, and security.