So there is the long standing debate of GUI Vs CLI in both the server and Networking world. There are quite a few angles to argue and I know that in this one single post I am not going to cover 100% of them and I am going to keep emotion out of this and stick to the facts and try to do a “Qualitative review of the two

Lets first reference one site that already did a majority of the work in comparing them and I also love giving credit where credit is due: In this we see that the GUI is labeled as easier to learn and this is the first point I will touch on. I understand the “easy to learn” aspect of things and it shouldn’t take a degree in rocket science to learn this stuff; however, when you make something to so stupidly easy you find people making claims of “I am a Network Engineer” or “I am a systems administrator” because they were offered the capability of just selecting a few things and it just worked. Take for instance in the Juniper ScreenOS GUI when you create a static default route there is a little check box that says “Permanent”. Few understand what this really does and without sufficient education will just think this is “good practice” and check it. Does everything work? Sure it does, until you want link redundancy or route redundancy.

In a command line environment, even with all but the BASIC knowledge, this option is at the end and not stereotypical of your standard “ip route next-hop” or “set route next-hop” what you would first learn when doing basic networking. So, this is where the GUI can cause problems for end users. Is this good for support business? You betcha! This is a double edged sword so I won’t go much more on it as I have been paid in the past to fix mistakes of “in house” IT; however, too often I find myself coming in after a “Engineering company” and fixing these issues. If you ask me, if you aren’t willing to learn how to manage systems from top to bottom you shouldn’t be in this field. Don’t just learn the GUI or the CLI, learn both and learn the CLI more because too often you’ll find yourself trying to manage a situation over a slow link and the GUI eats valuable bandwidth compared to a SSH session that doesn’t.

Secondly, the link lists the GUI as having a better multitasking capability. This is wildly dependent upon the type of shell you are using; however, for most networking gear this is the truth. But depending on what you’re doing you may find yourself in an endless loop of “refreshing” your pages that are open if the GUI is not correctly setup to refresh automatically. Score 1 for GUI on this whenever it is you really need that capability.

This posting has great points about the GUI and it’s invaluable multitasking capabilities. However, do take notice that both the Author and I share the common view the “user friendly” is a subjective term. The CLI is friendly to me and the GUI is not; thus, it completely smashes that ridiculous point and it has nothing to do with intelligence of the end user. Like the Author of the article stated (in a nutshell) “DOS users had a hard time with Windows GUI”.

Just to boot even Microsoft has realized that the CLI has a lot of potential as of recently! Take Exchange 2012 and how a majority of tasks can only be performed using PowerShell? If the market were really headed in the direction of GUI only I don’t think Microsoft would take what they are known for (simply and easy to use GUI) and incorporate an improved CLI with their products. Some like to say that a GUI can mature enough to do ALL the tasks of the CLI; however, I don’t believe this is entirely true in itself without creating a clustered mess of a GUI. Also, the GUI can NEVER taken the power, manipulation and automation strengths the CLI has and will always have.

One thing is for sure, when your primary link dies or your device locks up from the GUI side and you have to use OOB management you don’t want to fuss with the GUI and waiting for it to load. Also, in a hurried situation I have seen people click on something in a rush and then sit in horror as something was turning off or going completely down the toilet.

Where the GUI has strengths the CLI has the weakness, where the CLI has the strength the GUI has the weakness. I am not advocating that one should rule over the other; however, I am advocating learning BOTH so that if you find yourself interviewing at a job and the only administration you have done is through a GUI, and they have infrastructure that is CLI only, you won’t look like you’re just some kid who poked around in a GUI and called himself an expert. Also, I stand by the belief that the CLI makes you a better engineer because it forces you to understand the flow of setting up devices and understanding protocols better. I am not saying that learning the interpret tcpdumps is needed (in fact I think that is insane) we all know that WireShark is the best tool for this; however, debugging ScreenOS and figuring out why traffic isn’t egressing is much easier on the CLI when you’re able to quickly look at the mode of the interface, that policies setup and do filtering through your debugs to narrow the output.

Comments are closed.