I have a confession to make, one that is hard at times to admit.
Okay. Deep breath, here goes.
I’ve spent far too much time messing about with the command line interface on networking equipment in an inefficient, error-prone attempt at network management.
I know, it hurts to admit it. It’s okay, we’ll get through this together.
If you’re a network engineer by training like me, this may be hard to accept. After all, mainly through the long-running certification programs of Cisco as well as other vendors who followed their example, we’ve become intimately familiar with the deepest depths and tiniest niches of these arcane, syntax-heavy interfaces with their peculiarities and unintuitive behaviour.
We’ve pored over the command references and spent hours upon hours practicing the particular sequences of commands required to do what should be simple tasks in today’s networks, from establishing routing protocol neighbour relationships to implementing access control lists.
Indeed, it’s easy to feel threatened by people suggesting we should get rid of the CLI. With so much time invested in it, when we see motions made to push it aside, we can get defensive; by devaluing the CLI, aren’t those who wish for its demise also devaluing our entire skill set? How will we continue to be valuable if this core part of our hard-earned skill set is removed from devices in the future?
My answer is no – the downfall of the CLI is not to be feared. And in fact, it represents a great opportunity for network engineers and networking as a function within the wider business to become more, not less valuable over time.
There is a caveat, though; this only has the potential to come true as long as you have been studying for the right reasons and learning the underlying operation of the protocols and systems you are interacting with through the CLI, not just the arcane peculiarities of the CLI itself.
Do you understand the way BGP operates between autonomous systems, or how OSPF area types impact your network design? How about adding entries on a border firewall blacklist, or setting a Wi-Fi access point to talk to its controller? Great – you can make valuable decisions on network design and operation, before, during and after the network is made, and with the CLI replaced with more modern, efficient methods of network device configuration, you’ll actually have time to do so.
But if you’ve just been memorising strings of CLI commands, you have a bigger problem. What you’ve learnt can be useful, yes – for as many vendors and device families as you’ve studied – but ultimately that function can and will be replaced by smarter network management systems applying intelligent abstraction to make these tasks easier and easier to accomplish, without the use of a vendor-specific CLI to save time, money and troubleshooting.
In effect, what the removal of the CLI has the potential to do is increase the value of networking as a profession, and increase the value of the networking team in the average enterprise to the rest of the business. The more time we as networking professionals can spend on tasks such as improving network performance through design iteration, implementing support for new classes of applications, and working to reduce the operating cost of the network as a whole, the more valuable we are to our employer, the industry and the world.
Is that a bit of a scary step to take? Absolutely. By poking our heads up above the network configuration trenches, we’re exposing ourselves to topics, people and environments we might not be familiar or comfortable with, and we might long to return to prodding away at the keys of a console terminal at all hours of the day, squeezed in between two racks in the data centre.
But ultimately in technology, if we aren’t learning, we aren’t growing. Without updating and expanding our base of skills, there will come a time when what we know simply isn’t relevant any more – just take a look through the material you learnt on your certification journey, for some great examples.
How many Frame Relay networks have you run into lately? How about ATM, or IPX?
Don’t be afraid of expanding your domain outside of the technical, either. You’ll find it a lot easier to convince decision makers your way is the right way to go if you speak their language, and you’ll understand them a lot better as well. A little can go a long way here and help you keep moving.
So, if the CLI is such a time-suck, why is it still around, still taught so heavily and relied upon?
It has always struck me as a little odd that for an industry driven by higher speeds and lower latency, the massive inefficiency and antiquated nature of the CLI has been not only allowed to continue, but been actively promoted through years of training and certification courses. There must be a reason, right?
I believe that in today’s network device landscape, the CLI is primarily a tool to promote vendor lock-in by training network engineers to rely on and value it so highly.
Yes, devices can be configured quickly by the CLI for quite complex configurations… by an engineer with several certifications and hundreds of hours of training in using it. Despite having spent a lot of time myself on my own home lab setup practicing these very commands, I’m realising more and more this is not a good use of our time day-to-day; after all, very complex sums can be calculated using an abacus, but a computer is a much more reasonable choice today.
By getting network engineers highly invested in their CLI with its syntax and quirks, network equipment manufacturers create a barrier to adoption of another vendor’s equipment. To learn an entirely new interface and move away from their hard-earned knowledge is difficult for many engineers to do, leading to stagnation and a lack of innovation in choosing equipment.
At the end of the day, remember that the devices you or your employer choose for the network are a tool; they are there to work for you, not the other way around. Keep learning both wider and further, and you’ll not only find yourself better prepared for your next career move, but you’ll also become a more rounded and fulfilled engineer – and person – as a result.