Know the Process, Not the Tool


If there is one thing that amuses me as of late, it’s the “death of CLI” talk that I’m starting to see coming from many proponents of software defined networking. They like to talk about programmatic APIs and GUI-based provisioning and how everything that network engineers have learned is going to fall by the wayside.  Like this Network World article. I think reports of the death of CLI are a bit exaggerated.

Firstly, the CLI will never go away. I learned this when I stared working with an Aerohive access point I got at Wireless Field Day 2. I already had a HiveManager account provisioned thanks to Devin Akin (@DevinAkin), so all I needed to do was add the device to my account and I would be good to go. Except it never showed up. I could see it on my local network, but it never showed up in the online database. I rebooted and reset several times before flipping the device over and finding a curious port labeled “CONSOLE”. Why would a cloud-based device need a console port. In the next hour, I learned a lot about the way Aerohive APs are provisioned and how there were just some commands that I couldn’t enter in the GUI that helped me narrow down the problem. After fixing a provisioning glitch in HiveManager the next day, I was ready to go. The CLI didn’t fix my problem, but I did learn quite a bit from it.

Basic interfaces give people a great way to see what’s going on under the hood. Given that most folks in networking are from the mold of “take it apart to see why it works” the CLI is great for them. I agree that memorizing a 10-argument command to configure something like route redistribution is a pain in the neck, but that doesn’t come from the difficulty of networking. Instead, the difficulty lies in speaking the language.

I’ve traveled to a foreign country once or twice in my life. I barely have a grasp of the English language at times. I can usually figure out some Spanish. My foreign language skills have pretty much left me at this point. However, when I want to make myself understood to people that speak another language, I don’t focus on syntax. Instead, I focus on ideas. Pointing at an object and making gestures for money usually gets the point across that I want to buy something. Pantomiming a drinking gesture will get me to a restaurant.

Networking is no different. When I started trying to learn CLI terminology for Brocade, Arista, and HP I found they were similar in some respects but very different in others. When you try to take your Cisco CLI skills to a Juniper router, you’ll find that you aren’t even in the neighborhood when it comes to syntax. What becomes important is *what* you’re trying to do. If you can think through what you’re trying to accomplish, there’s usually a help file or a Google search that can pull up the right way to do things.

This extends its way into a GUI/API-driven programming interface as well. Rather than trying to intuit the interface just think about what you want to do instead. If you want two hosts to talk to each other through a low-cost link with basic security you just have to figure out what the drag-and-drop is for that. If you want to force application-specific traffic to transit a host running an intrusion prevention system you already know what you want to do. It’s just a matter of find the right combination of interface programming to accomplish it. If you’re working on an API call using Python or Java you probably have to define the constraints of the system anyway. The hard part is writing the code to interface to accomplish the task.

Tom’s Take

Learning the process is the key to making it in networking. So many entry level folks are worried about *how* to do something. Configuring a route or provisioning a VLAN are the end goal. It’s only when those folks take a step back and think about their task without the commands that they begin to become real engineers. When you can visualize what you want to do without thinking about the commands you need to enter to do it, you are taking the logical step beyond being tied to a platform. Some of the smartest people I know break a task down into component parts and steps. When you spend more time on *what* you are doing and less on *how* you are doing it, you don’t need to concern yourself with radical shifts in networking, whether they be SDN, NFV, or the next big thing. Because the process will never change even if the tools might.


5 thoughts on “Know the Process, Not the Tool

  1. Some interesting points. In addition, being able to visualise what you are trying to achieve, aside from the required commands at the CLI, makes you better at communicating requirements to other people. I know plenty of engineers who can sit at the CLI and get things done, but when you ask them to explain what they are trying to achieve, they either stutter\draw a blank or spew forth some incoherent gobbledegook that makes no sense to anybody.

  2. Pingback: Know the Process, Not the Tool

  3. CLI is good for two things, automation and short commands. that’s it. everything else, a GUI is better. The deep functionality argument is flawed. By keeping GUIs as second class citizens, CLI-biased environments perpetuate the myth that you need to use the CLI to get “real work done”. Of course it do. You have a crippled GUI, what do you expect? The answer is to make the GUI and the CLI first class citizens(ala powershell) not make the GUI some retarded children’s BS like in Linux (Gnome, XFCE, LXDE, Unity) and keep all advanced functionality in the CLI.
    this fellow explains it well.
    GUI is like a cockpit, CLI is like giving instructions over a phone. anything above extremely primitive commands the CLI turns into a hellish nightmare of manpages and a spaghetti of switches and arguments. discounting the hours wasted learning stupid arcana from 1970s, the time it takes to actually type the darn thing is impractical at best.
    again, the CLI shines in automation, scripting and short and simple commands. its rubbish for everything else.

    • For each of the two types, GUI and CLI, there are both exceptional and horrible implementations. I don’t think a GUI is automatically a cockpit. For any given product the “cockpit” will be the more effective of the two management methods. If you limit yourself to using one over the other simply because of philosophical reasons then you limit yourself as an IT professional.

      At the end of the day the only thing that matters is that you have an interface to get done what you need to get done. Who cares if that is a GUI or a CLI?

      • the cockpit analogy is the way the functionality is laid out, not its effectiveness. GUI as naturally object oriented, CLI is command oriented. obviously its super handy to type in a powershell cmdlet to enable something or change some setting. But as I said before my point is not to denigrate CLI’s usefulness, but to underscore how messy they get really fast.
        The underscore is to empower the user with intuitive and easy to use interfaces, not to tell them that GUIs are for idiiots who can’t learn the “way its meant to be”. (With that line of thought, assembly is the way its meant to be, all of you are pussies for using IDEs and high-level languages.
        Ironically CLIs are most effective inside GUIs, even X11 was primarily desinged to run emacs and xterm. With in-GUI CLIs you get drag and drop, Intellisense, scrolling, copy pasting and side by side viewing of multiple CLI processes.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s