DEVOPS VS NETDEVOPS: Why Network Programmability is NOT NetDevOps

In this post, I will discuss good old DevOps and how it compares with NetDevOps along with my take on why network programmability is NOT NetDevOps.

Now, to begin with, let me first share with you three jaw dropping statistics that go out to show why do we need NetDevOps in the first place. What do you think to be a typical number of Organizations that make network changes several times a year? I’d say that’s very common in most medium to large Enterprises. Well, as per a survey published in network world, there is about 44% chance that such a network change would lead to an outage. Now, what do you think, is the most common way to verify a network is functioning as designed after a network change is made? Well, 79% of the time it is done through manual checks such as using device CLI, inspecting configuration, and using tools such as traceroute and ping. Finally, what’s your guess on what is the average time to find and resolve a network issue after it’s reported? About 60% of the survey participants quoted that time to be anywhere from 1 to 5 hours. Let me summarize. Based on facts, pace of network changes is directly correlated with increasing frequency of outages, where each outage can take up to 5 hours to resolve, and majority of the network engineers are still manually verifying a network after changes are committed. There you go, we desperately need a better way to make and verify network changes. This is where we enter network programmability and automation.

Now, as opposed to popular belief, network programmability is not sufficient and that is not “NetDevOps”. Learning Python and Ansible along with data representation formats such as YAML and templates like Jinja is cool but that is only a piece of the overall puzzle. If you’re looking to transition your career as opposed to just learning a new skill, I’d strongly suggest you keep big picture in mind and deeply understand DevOps and NetDevOps before jumping into it with both feet.

NetDevOps is DevOps coming to Networking, it is NOT the other way around. Now, DevOps was a major shift that our cousins on the system admin side went through over the past decade and still going through to this day. As a DevOps engineer, your goal is to ensure continuous delivery. It is the combination of cultural philosophies, practices, and tools that increase an organization’s ability to deliver applications and services at higher velocity. Under a DevOps model, development and operations teams are no longer “siloed.” It is common to see these two teams merged into a single team where the engineers (i.e. developers, testers and IT operations folks) work across the entire application lifecycle and develop a range of skills not limited to a single function. At 10,000 feet, you can think of DevOps delivery pipeline to be consisting of Coding, Building, Testing and Releasing stages. If you know anything about DevOps, I am sure you have heard about Continuous Integration or CI and Continuous Delivery or CD. CI is a software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. Whereas CD is a software development practice where code changes are automatically built, tested, and prepared for a release to production. It expands upon CI by deploying all code changes to a testing or production environment after the build stage. Last but not least, there is Infrastructure as code or IaC, in which infrastructure is provisioned and managed using machine readable definition file (or Code) as opposed to CLI or GUI using software development techniques, such as version control and CI. Now, using IaC, makes configuration management much easier since now engineers can interface with infrastructure using code-based tools and treat infrastructure in a manner similar to how they treat software application code.

Now that we know of DevOps at a higher level, let me describe to you the tooling chain that’s used at each stage within the DevOps pipeline. Why is this relevant to you as a network engineer? Because tooling chain remains more or less consistent across the DevOps and NetDevOps paradigms. In DevOps, planning and creation of code happens using JIRA, Rally GitHub or GitLab. These are your source control management software aka version control systems. Jenkins or Travis CI are used for build verification which takes place as part of CI and CD stages. Docker, Ansible and Puppet are commonly used for stages of Configuration, Packaging and Releasing. Finally, monitoring, as part of feedback loop, is done using NewRelic or Splunk or Nagios or another monitoring tool of your choice.

Now, Beyond DevOps toolchain, and coming back to “Config as Code” part of the NetDevOps, you will need to develop some know-how of infrastructure components such as Linux, Containers and Kubernetes which is the open source orchestration platform, micro services, and some cloud fundamentals such as virtualization. In terms of network programmability, some familiarity with python, data formats such as YAML and provisioning tools such as Ansible would be super critical. Let me summarize. NetDevOps is nothing more than the combination of network programmability, i.e. “Network Config as Code” and end to end build, test, delivery and deploy automation in the form of NetDevOps pipeline using well known DevOps toolchain.

I will soon be discussing NetDevOps delivery pipeline in more detail and how you can get started.