Is there a future for CLI?
The future of CLI and how Network Engineers will interact with devices is a topic being discussed quite often.
ERRATA: link in tweet is broken, go HERE for the correct page
"I'll give you my CLI when you pry it from my cold, dead fingers" - said no #CCIE ever, they're busy automating their networks with Python to save time for more creative activities.— Gian Paolo (@gp_ifconfig) December 6, 2017
Just a few of them suffer the "CLI Stockholm Syndrome"https://t.co/jHkB4LQk5T pic.twitter.com/j8CDgCIBpA
Andrew Lerner wrote on November 2016:
By 2020, only 30% of network operations teams will use the command line interface (CLI) as their primary interface, down from 85% at YE16.
Sometimes the discussion leads to flame wars between those who love the CLI and those who see only a mix of API amd GUI as tools to interact with the network equipment.
Instead of just criticizing the existing model and demonizing the new one, it would make more sense to understand what are the actual needs of network professionals and try to push $vendors to produce something that actually works. Vote with your wallet.
I put in this post a mix of what I read/heard on various blogs, tweets, podcasts and chats with fellow network engineers.
I don’t attribute to myself any of these ideas, I’m just trying to clarify the topics for my own use. Some topics are simplified because a detailed discussion is out of the scope of this humble post.
The CLI we use today is almost the same that was available since the beginning of networking, a bunch of commands sent through a serial/telnet/SSH session.
Junior and experienced network engineers feel the need of something better to improve work/life balance and operate network devices more efficiently.
The new CLI modelAssuming CLI will not disappear soon, how can it evolve to be a modern tool?
Today’s CLI runs on the box itself, where the box can be any physical or virtual network appliance.
Almost all the network vendors are developing APIs that are supposed to allow to manage the device, with feature parity with CLI hopefully.
Some vendors are using an approach that seems simply wrong using API to send raw CLI commands:
Another solution is to move the CLI on top of API and make it work on the same data model to manage the device configuration:
The CLI itself runs locally as an application on the box or on a remote management workstation, it makes no difference.
The GUI works at the same level of the CLI, it can be provided by the vendor or any other custom software for network management.
Perhaps this model of CLI is already being applied or developed by some vendors, Juniper’s Junos seems the closest one to this model:
Aruba puts API aside CLI on its new 8400 switch.
CLI on top of API?
What are the advantages of putting a CLI on top of API instead of aside?
It forces the vendor to implement an API that includes all the possible commands and options, not just a subset.
It allows to build custom GUI, CLI and orchestration tools with the same features of the native tools.
It maintains the CLI as a quick and known troubleshooting tool for expert networking engineers in case of necessity. No one wants to write code to collect data for a quick troubleshoot.
You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. Buckminster Fuller
New management tools have a great potential to improve the lives of network engineers but in the end I think we’ll still want a CLI when something goes wrong.