For more details, please see ourCookie Policy.

Federal Insights

CLI is Dead

by tbraly ‎03-13-2017 08:43 AM - edited ‎03-15-2017 01:53 PM (12,326 Views)

The much-loved Command Line Interface (CLI) with its simplistic, yet complex set of instructions entered one line at a time is dying. With major changes to the IT landscape, introduced with digital transformation and IT modernization, the approach can no longer keep up. Per Gartner by 2020 only 30 percent of network operations teams will use the CLI as their primary interface. I believe that number should be closer to 1 out of 10. Here’s why:


Too much technology debt. Let’s face it, the command line hasn’t changed in over 20 years. As a result, new approaches to solve issues have simply been bolted on, while leaving the legacy commands intact. This leads to unnecessary complexity and confusion. As a result, government leaders are forced to provide costly advanced training for their own personnel or hire expensive consultants. Ultimately this is unsustainable, driving the need for a change.  


An inability to support a network-wide view. CLI is used to manage a single network element at a time, an ineffective approach for today’s networks. Yes, vendors have introduced stacking and fabrics to allow multiple elements to appear and be managed via CLI as one; however, that approach only scales so far. Additionally, since each network element is its own entity, complex protocols like Border Gateway Protocol (BGP) and Multiprotocol Label Switching (MPLS) were created in an attempt to give a single element an optimal network-wide view to best route traffic and provide quality of service (QoS). However, too many times congestion downstream goes undetected by these protocols requiring manual intervention via CLI. This element-by-element manual intervention is complex and time consuming, thus preventing real-time adjustments to changing government missions.


Exponential growth of the Internet of Things (IoT). The network landscape is changing and the number of connected network elements is growing exponentially. Gartner has predicted that there will be 8.4 billion connected things this year and over 20 billion by the year 2020. Using just CLI, there is no way keep up with the provisioning of new devices, let alone manage the micro segmentation that’s needed to secure these devices. Without a more efficient approach, agencies will be unable to take advantage of the insights and functionality IoT enables.


Changing user expectations. Users demand instantaneous services. The time that it takes to implement services one line at a time using CLI is impractical, and it is typically the highly skilled and expensive engineers needed to do it. As demand continues to increase, we will eventually reach a point where there are not enough experts to manage the growth, degrading the user experience.


Luckily, there is a simple solution. It’s automation.


Automation abstracts the complex tasks necessary to provision a service or application into an action. This action takes just the variables that are unique to that instance as input. For instance, provisioning a port for a VoIP phone requires configuration of the Voice VLAN, turning on POE power, configure LLDP-MED, etc, but when you look at the details or variables needed to do the job, it’s only two things: the device and port. Everything else is a constant that can be defined in a simple template that is pushed programmatically using any configuration management protocol a device supports. This may be via CLI, SNMP, NETCONF or RESTAPI. The protocol that is used should not matter in automation because it should be transparent to the administrator. The administrator just needs to say “set port 32 for VoIP on switch a."


Writing scripts for network automation isn't new. What’s new is a concept called If This, Then That (IFTTT) frameworks and open cross-domain automation. What are these? Networking scripts, now called micro services – small lightweight actions that do a specific task – can be chained together with server and storage operations. Best of all, through the open source community that the StackStorm project has created, one can even wind up the windows on your Tesla car.


Brocade provides an enhanced and vender-supported version of StackStorm called Brocade Workflow Composer. It takes IFTTT to the next level providing a framework where sensors detect changes and send triggers that get picked up by rules that map these triggers to actions. If multiple actions are need to complete the task, we call those workflows. These sensors, rules and actions are delivered in packs. Administrators can take advantage of the pre-existing turn-key packs, customize existing packs, or create their own packs from scratch.


Creating packs from scratch may sound daunting; however, it’s more simple than you think. For example, a StackStorm user created the Tesla pack by using an existing Tesla Python Library, writing just the action definitions (in YAML) and then wrapping the Tesla Python functions in a StackStorm Python Runner Class. This runner class is typically only a few lines of python code passing the variables onto the Tesla API and returning the results back to StackStorm.


The Transformation to Automation


Now the bad news, this transition to using automation requires new skills for engineers or system administrators that are used to only using the CLI. These personnel need to become skilled in programming fundamentals and logic. The good news is engineers and admins are great at solving problems, and have basically been writing complex programs one line at a time, device by device using the CLI.


The other barrier is the comfort level with automation. Case in point, I was recently presenting on automation to a mixed group of individuals from software developers, program managers and network engineers. One network engineer immediately objected, stating the leading book on BGP is 3” thick and there is no way automation could handle that level of complexity. With IP fabrics and automation, this seemingly impossible task is a reality. Tools like Brocade Workflow Composer, can build out an entire EVPN-BGP network hiding all the complexity of communities and route-reflectors.


This all reminds me of 10+ years ago, when the argument was Plain Old Telephone System (POTS) vs. Voice over IP. We all know how that ended. Now is the time to become versed in automation.



Automation is an important tool as agencies adapt to digital transformation and modernize their infrastructure. Keep following Federal Insights’ Tech Corner blog for more updates on technologies that can help you better meet your agency’s mission: