NetDevOps Concepts – An Introduction

As the networking industry moves to embrace NetDevOps, there are often many terms used that network practitioners are unfamiliar with. This can lead to many people feeling unsure about what role a new technology could play in their organization, or even being afraid to ask for clarity about a discussed concept. In fact, there are a few questions we see asked time and time again.

“What is CI/CD, why would it have a pipeline, and what does that have to do with my network?”

“What does IaC or SoT mean?”

Or even, “What is NetDevOps anyway and why should I care?”

In this series of blog posts, we will delve into NetDevOps in a way that ensures you have familiarity and a basic understanding of what NetDevOps is, as well as some of the key components. We will also talk briefly about how, and why, you might apply a some of these concepts to operating your network.

What is NetDevOps?

Many fantastic blog posts and presentations discussing what NetDevOps is as a philosophy exist, and I won’t revisit all of their points here. Suffice to say that NetDevOps brings key concepts from the DevOps movement, which we’ll talk about deeply in subsequent blog posts, and applies them to operating and building networks.

With the proper application of NetDevOps concepts, you no longer have to think about your network as static, rigid, and fragile. Instead, you can start to treat it as something flexible and responsive to your desires or business needs. Some examples of these concepts include:

• Continuous Integration/Continuous Deployment (CI/CD)
• Infrastructure as Code (IaC)
• Source of Truth (SoT)
• Minimum Viable Product (MVP)
• ChatOps

As for seeing these concepts in action, let us say that you need to deploy a new site to your corporate VPN. Without a NetDevOps approach to managing your network, you could spend a week fighting by hand to build the proper IKE/ISAKMP settings for the tunnel and documenting the site in your systems, applying changes, and then testing to ensure everything is functional.

However, if you are using a few key NetDevOps concepts to manage your network, your process could look more like this:

• Message new vpn site to @my_netdevops_bot in your chat application (Slack/MS Teams/Webex Teams)
• Fill in the site name, equipment type, and other metadata as prompted by the bot.
• @my_netdevops_bot uses that information to:
  • Create the site in your Source of Truth (SoT)
  • Merge a Jinja template with the relevant data from your SoT
  • Present you with the rendered configuration in chat application
• Upon approval of the change, @my_netdevops_bot will connect to the devices, and deploy these configuration changes
• @my_netdevops_bot then queries the network (or other systems such as monitoring systems) to determine if the change was successful and present you with confirmation in chat.
  • If the change failed for some reason, @my_netdevops_bot can then start to troubleshoot some basic things on your behalf and present that information to you as well.

This is not a far-fetched or cutting edge example, this is just one of the many ways in which we see the application of NetDevOps concepts on a daily basis across all types of organizations.

“But…”

Usually, about this point in the conversation, there is a “But…” lurking off in the wings. Some greatest hits include, “But my network is too old” or “But my network is too unique.” My personal favorites are, “But my network is too large/too small!” as if there was a mythical Goldilocks zone where these concepts apply. The list goes on, but for almost every exception raised, there is an answer. Most of these can be addressed by two main responses.

First, no one is suggesting that you go directly from zero to the scenario described above. Embracing a NetDevOps mentality and approach to your network operations is an iterative process. Applying just a few of these concepts (and not all of them) to a single small element of your network is the best way to begin your NetDevOps journey. Even small, simple steps can pay large dividends. If you are manually generating device configurations, start to look at building a templating system for your device configurations and keeping it as code in a Git repository. This first step of only generating the configurations, leaving the engineer to actually qualify and apply them, can pave the way for many other steps in the future. Even in and of itself, simple configuration generation from a template can provide time savings and operational wins by removing human error and ensuring there is a single standard configuration.

Secondly, no network is too special to take advantage of these concepts. Is your network very large and complicated? Is literally every single component unique? Pick a single place in your network to start implementing a Source of Truth (such as NetBox). Having the data in an easily accessible API and/or GUI, and in a known standard format, will show value immediately for any other concepts you wish to apply. Does your network lack coherent standards? Start to enforce them on a single item of configuration, such as the AAA configuration, via Infrastructure as Code principals. Ensuring that the AAA configuration on all devices is a known/expected value at all times is extremely valuable from an operational and security perspective. Your compliance auditors will thank you!

Each of the above strategies relies on the concept of a Minimum Viable Product. When you start to embrace NetDevOps concepts for operating your network, do not expect to solve all of your problems in the first try. Pick one straightforward problem to solve. Build your solutions and tooling to solve that problem, then begin using it in your day-to-day work. If it is successful, look at adapting your tools to solve additional problems. As described above, perhaps you tackle only the AAA configuration first. When that is fully managed in a Source of Truth, and as code instead of raw device configuration, you can expand to managing the SNMP configuration on all your devices as well. Next, you could tackle management ACLs to your devices or NTP and DNS settings, really it’s up to what makes sense in your network. In this way you will rapidly expand the portions of your network that are being managed via NetDevOps.

Next Steps

This is the first in a series of posts on NetDevOps concepts, and I highly recommend staying tuned for the subsequent posts where we dive into some of these concepts in greater detail. We’ll have use cases and examples for each of them, including how to tie these all together into a coherent network automation strategy in the end.