Introducing Itential’s NetOps Pipeline & API Services
DevOps has become the latest aspiration for technology companies everywhere, and the networking space is no exception. Unfortunately, for network engineers, the network industry presents challenges that don’t necessarily align with pre-existing patterns that software engineers use to implement those methodologies.
To better understand the problem, it’s useful to abstract the traditional CI/CD pipeline into its basic phases and look at how you approach this in traditional software development. Before you can get started, you need a place to store all of your code and changes. This is best done in some version of source control like git, or CVS. Once, you’ve established where you store your code, you are ready to build your pipeline.
- The first phase is the build phase. This is where your various changes are merged together, and your code is compiled into its complete and final form.
- The next phase is the testing phase. In this phase, we run any tests we have available which might include unit, regression, and performance.
- Finally, we have the deploy phase, where we actually put the code on the target platform. Now anytime a change is made to source control, we can automatically kick off the process to push that change to the target platform with confidence that the code compiles and is well tested.
A trivial representation looks like this:
Applying CI/CD Pipelines to the Network
If we try to apply that strategy to network configurations, we run into a couple of problems. First off, there isn’t generally a consistent source of truth. You might have several templates that are each responsible for chunks of the configuration, but the actual final built version of each configuration is only available on each specific device. In this scenario, you can version control your templates, and kick off a build process each time they are changed. However, you aren’t building the entire configuration, so the only way to achieve the actual result of the build step is to apply it to the device. This brings up two very big problems.
- First, you don’t know if the configuration that you are adding to the device is actually going to be accepted by the device. Your templates could have errors, or the code that exists on the device might conflict with the changes you are making. If you are lucky, the device rejects all the changes. If you aren’t so lucky, the device accepts some of the changes, but not all of the changes, leaving the device in a potentially unstable state. If you are really unlucky, the changes are made, but the result of the configuration isn’t what you actually intended.
- The second glaring problem. We skipped over the test phase before we deployed our changes! Therefore, we end up doing our testing on the live network instead of matching the desired state above and then we end up with something more like this:
If anything goes wrong in testing, we have to change the device again in order to restore it to its previous configuration. So, we should probably go back and add a step to do a backup before we deploy.
We also try to mitigate risk by doing these changes during scheduled maintenance windows when an outage would have the least impact. Wait, isn’t a major point of doing CI/CD to make changes as they happen? By implementing this gating mechanism, we are now actively violating the core principles of these methodologies. FAIL.
The NetOps Pipeline
At Itential, we’ve been working to overcome these problems for our customers, and in order to help customers embrace Network Infrastructure as Code methodologies, we are building API services that better enable network engineers to achieve these goals. We also understand that you can’t just up and change everything you do to conform to some new paradigm. Our API services attempt to align with traditional software engineering practices while staying flexible enough for customers no matter their level of automation they’re at. In order to do that, we’ve tweaked the traditional pipeline slightly as what we call the NetOps Pipeline for Network Infrastructure as Code.
Itential API Services
Unfortunately, in the network world, you can’t easily “compile” your configurations. To accommodate for this, we’ve broken the traditional build phase into two distinct phases. The first of these we refer to as the build phase. These services are designed to help you build complete configurations from external data and/or blocks of pre-built configurations. We also allow you to create config dynamically from collections of industry-tested templates and code (TemplateIDE).
The other added phase we call the “validate” phase. These services exist to make sure that the configuration you are deploying actually makes sense. In our previous network example, we don’t know if the constructed configuration would even be accepted by the device. Our validation services (Config Validator) can check to see if a configuration is compatible with the device without having to deploy it. The combination of these two phases helps approximate the type of work a compiler might do during the build phase.
Our next collection of services are our testing services. These services help make sure your changes do what you intended them to do. For example, if you are changing an ACL policy on a device, you can run a series of tests against that policy to simulate what would happen for multiple scenarios (Policy Analyzer).
Last, but not least, we have our deployment services. As the name implies, these services deploy your infrastructure. One of the challenges in the networking world is the lack of a centralized source of truth. Just because you create away to keep track of your device infrastructure changes, doesn’t mean that other integrated systems will automatically recognize your changes. In addition to supporting device changes (Automation Gateway), our services are designed to help you keep all of your other systems in sync anytime you make an infrastructure change.
Itential is committed to helping network organizations adopt modern agile processes through automation. By continually making more services available, we hope to lower the barrier to adoption to Network Infrastructure as Code. We’d love to hear what you think and contribute back to these concepts as we continue to innovate the networking domain.