Why Network Engineers Need to Learn Programming

Why learn programming? Are we really in a true transition or simply lost in the hype? As network engineers, sometimes we get lost in the minutia of learning programming skills based on our experience with compilers and debugging tools that still haunt from our technical college days. Often times the network programming debate isn’t even focused on the right question.

For example, network engineers don’t need to become proficient in learning programming languages such as C++ or Java to build applications. More to the point, one could argue network engineers need to learn coding skills to interact with infrastructure related APIs using scripting languages like Python and Ansible.

Moreover, as we extend this programming discussion beyond “coding skills,” they’re certainly other key programming tenants that complete the journey from manual CLI to network automation. In other words, programming is more than programming languages and network automation is more than coding. Programming “frameworks” extend to design principles, life-cycle management, and operational methodologies. Before we go into the nitty gritty of network automation, let’s unpack some of the main drivers for investing one’s time when committing to making the transition from network engineer to network automation programmer.

Business Value

Network capital and operation costs continue to grow. The growth of data and devices is starting to outpace team capabilities, making manual approaches with GUIs and CLI nearly impossible. Yet up to 95% of network changes are performed manually, resulting in 75% of the overall network costs due to operational costs. Automation offers better consistency which lowers risks and costs. Working from home has exasperated these challenges which demand automated network solutions in order to meet demands at scale.

Make Yourself More Valuable

Learning programming skills allow network engineers to do their job significantly better, while increasing their market value. Cisco DevNet Certifications provide a clear path for learning the key programming skills. For a network engineer in transition, Cisco DevNet certifications uniquely walk the line between open source and Cisco specific skills. The DevNet certifications layout a path to master Python, Ansible, Terraform, GitOps, ChatOps, PyATS automated testing, Docker, and Kubernetes and many more. More importantly, these skillsets are aligned with specific Cisco solutions and APIs via concentration tracks for student to select based on their interest.

On the Job

More and more network engineers are responding with programmability and automation to make improvements to their respective day-to-day tasks. Programming for network engineers is a journey across many skills, use cases, best practices, languages, and tools.

Getting Started

Scripting tools and programming languages such as Python and Ansible are great starting points for automating repeatable tasks. Often times, the initial use case target for automation are the daily network hygiene tasks that immediately benefit the individual contributor. (i.e., shutting down unused ports, changing SNMP strings, and show commands).

DevOps Principles

More and more network teams are adopting DevOps best practices to break down silos between network Design and Operations. This is a cultural shift where both teams (NetOps) work closely together. This collaboration must happen early in the planning and design phases to combine strict standardization and testing to achieve a baseline for automation. In order to achieve NetDevOps, each use case for automation must be defined to meet both functional and non-functional requirements to provide the blueprint to automate each task or steps. The collective team must therefore agree to manage configurations with automation vs one-off connections accessed out-of-band using manual CLI/GUI configurations. This permutation of automation focused on the network is known as NetDevOps.

In addition to a cultural shift, an emphasis on building and maintaining an automated test lab is paramount to succeeding with automation. The test lab is needed to properly create rigorous standardization by validating all automated configurations using code, version control, testing, and peer review. By investing more time and effort in development, translates to less errors manifesting during downtime windows to push changes into production. This is not to suggest that changes to production should be completely automated, most are tested with full automation but deployed with partial automation within a manually approval chain and checks. None the less, by leveraging Network as Code (NaC) in the test lab, any version of the network becomes quickly available for rebuilds, artifacts, or root cause analysis.

Advanced

Earlier we asserted Network Automation requires programming skills beyond learning coding languages. Network Automation also extends beyond DevOps best practices. Modern networks consist of several domains (access, campus, WAN, data center, and cloud edge), each operating in a fluid state of as-is (legacy/brownfield) and future state (modernization/greenfield). There are many architectural and domain specific factors to consider when Network Programmers crawl, walk, and run towards fully automated networks, within and across multiple domains.

Command Line Automation vs YANG Data Models

CLI scripting is very popular to automate sending serialized commands to stand-alone routers, switches, firewalls etc. by using Ansible playbooks or Python libraries such as Netmiko/Napalm/Nornir. CLI based scripting works well to a point but as the automation use case evolve, additional plugins and frameworks are typically needed to thread together multiple scripts that share data and logic. Likewise, more programming skills and techniques are required such as parsing text, conditions, loops, Jinja2 templates, saving output to external files, and data bases. With that being said, CLI scripting introduces its own dependencies and considerations the network development team must take into consideration. YANG Data Models help to normalize across multi-vendors by working with Netconf and structured XML. Data. With data models we can change configurations or parse operation data directly. Consequently, NETCONF/YANG is another candidate for your learning map.

Domain Controllers

Software-Defined Networks or SDN (Access, WAN, and DC networks) provide controllers with a northbound API as opposed to a GUI/CLI to access the configuration and operation state of an entire fabric (underlay/overlay). Domain controllers greatly reduce the logic and multi-threading required to manage an SDN as code. Coding scripts with a one-to-one relationship to APIs can be quite time consuming and daunting. Not to worry Cisco has an easy button here. Cisco SDN solutions (Meraki, DNAC, ACI, SD-WAN etc.) publish a Python SDK (software development kit) to simplify coding to our controller APIs. This way the customer can focus on scripting to a use case and consume the methods provided as a wrapper to the actual API calls.

Orchestration

When dealing with multiple controllers or inventories of standalone devices using only libraries of scripts is challenging to manage the automated scripts manually. Instantiating scripts using workflows managed by orchestration engines can include triggers, events, and analytics while managing the exact order of automated scripted steps. Orchestration tools typically provide governance, visibility, RBAC, workflows, and reporting capabilities to round out the gaps from scripting tools. For example, Ansible Tower/AWX manages workflows for Ansible Playbooks. For those exploring multi-vendor with YANG Data Models the Cisco Network Orchestrator (NSO) provides a simple to use platform to manage both YANG data models and non-native YANG devices for both brownfield and greenfield environments.

Multi-Domain Orchestration

The annual Cisco Live conference is a perfect example of needing to deliver at scale with a very small runway (three days) to orchestrate delivering and operating the entire Cisco Live infrastructure. The Cisco Action Orchestrator provides over the top orchestration to manage various domain controllers, and APIs for compute, network, storage, and cloud. Action Orchestrator can manage both API and CLI scripting workflows across many tools (Python, Ansible, Terraform, Bash etc.). Cisco Action Orchestrator provides database adaptors for visualizing key experience indicators via dashboards and other valuable feedback not possible from scripting tool alone.

Key Takeaways

Digital transformation is gaining momentum and a powerful force in the new normal. Transformations tend to shine the light on bottlenecks. We as network engineers can no longer hide behind our own short comings or dependencies on manual processes. Now is the time for network architects, engineers, and operators to team together with the appropriate programming skills. Collectively this NetDevOps team will build and manage the Networks as Code (NaC).

Why Network Engineers Need to Learn Programming

Programming skills add value to the business and when coupled together with traditional network expertise these hybrid experts command higher pay and accelerated career advancement. Clearly there are many moving parts to deliver automation into production at scale. Don’t do this alone! Cisco offers services supporting orchestration solutions such as NSO and Action Orchestrator provide layers of abstraction and low code workflows to make operationalizing automation much simpler. Good luck.

ABOUT THE AUTHOR

Tony Dubiel is a Product Solution Architect for Red Hat’s Ansible Automation Platform. As an architect and engineer, he has explored all aspects of Enterprise IT with over 20 years of Telecommunications and Network experience. Tony is uniquely positioned to align DevOps best practices with Day (0-2) network operations. He is currently an active CCIE #10844 triple (DC, R&S, and Voice) and Cisco DevNet Professional certified.