Searching|for|consistency|in configurations

The networking industry has gone through a drastic shift in the past decade. I remember when I was first diving into large scale campusanddatacenter infrastructure. I was looking for any tips and tricks to ensure that my text-based configurations were consistent across every device within a given location. Things like find/replace, macros, spreadsheets, and even some rudimentary automation with tools likesed and awkwere lifesavers. They helped me get close to consistency in configurations. However, it did not really help when I needed to move configurations between devices of different operating systems (which really made it difficult when supporting a campus of IOS at the edge, NX-OS in the datacenter and core, and IOS-XE at the WAN edge). Sure, we all had "configuration" in "code" that made a network run, but getting it deployed was not the easiest thing to accomplish consistently. 

Software defined networking (SDN) was supposed to bring all this frustration to an end -allowing network engineers to focus on business-intent to drive the network, rather than box-by-box configurations. The controllers required for SDN-enabled networks centralized policy and configuration -making it accessible through a slick-looking web UI that enabled deployments with a few mouse clicks. The future was bright and network engineers would have tons of free time to upskill and better themselves. 

...Then the other shoe dropped 

Everything seemed fine when the controllers were initially deployed -configurations were consistent, observability increased, and everyone seemed generally happy. However, as time rolled on, it was revealed not to be the panacea that everyone hoped. The web UI created a similar problem experienced by public cloud providers and virtualization hypervisors -namely that every engineer was becoming an expert in "click-ops." Gone were the days of using "Find and Replace" to edit configurations. Every engineer now had to learn how to translate configuration to the UI, and then repeat that process consistently every time a new deployment needed to happen. Method of Procedure (MOP) documents had to go into excruciating detail to ensure that two different engineers would deploy a configuration change in the same way... with the same metadata... every time. On top of that, what if the engineers had to manage multiple fabrics or campuses? Each with their own controller? The amount of clicking could be enough to require a sharp increase in the number of mice purchased within the IT department! 

Programmability to the rescue... right? 

The (simple) answer to this problem in everyone's mind was "let's use programmability." The SDN controllers were all driven by APIs and had included SDKs that enabled the rapid prototyping of scripts and code that could automate the change process and simplify the amount of work done by network engineers. Large MOPs could be scaled down to only include naming conventions and metadata tags. The (Python) code could handle the rest. This transition worked for automating a single controller -but spanning across domains (or even clouds) was made difficult by the availability (or lack thereof) of SDKs, as well as portability of code across versions of on-prem or cloud infrastructure controllers. 

So Now What...? 

Thankfully, there is a better way. Using Infrastructure as Code (IaC) tools, such as RedHat Ansible or HashiCorp Terraform, the complexity of interacting with controllers and devices using APIs or SDKs has been abstracted away into easy-to-digest domain-specific languages (DSLs). These DSLs allow for rapid development of configuration, ease of archival using a VCS, and best of all, can be written to interact with multiple devices or types within a single file! While not 100% perfect, these IaC tools allow for a quick way to orchestrate configuration across one or more domains. 

Now that we've talked about the 'why', are you ready to learn more about IaC in the context of infrastructure and clouds? Here are a couple suggestions:

• If you're going to Cisco Live this June in Las Vegas, make a plan to stop by the DevNet Zone at CiscoLive! We will have myriad options and delivery methods to learn, both in-person and virtually.
• Visit the Cisco DevNet website to learn more about Infrastructure as Code

Join our daily livestream from the DevNet Zone during Cisco Live!

Stay Informed!
Sign up for theDevNet Zone Cisco Live Email Newsand be the first to know about special sessions and surprises whether you are attending in person or will engage with us online.

We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel