The
use of graphical user interfaces (or GUI) to configure network
devices can divide the network engineering community. Network engineers
can be either GUI lovers or haters. I’ll confess right now that I’m a
CLI fan and reluctant to use the GUI. As far as I am concerned, the GUI
is a "limited-view" of the network device, a necessary evil for
first-time users.
Real engineers use the CLI or an API, or so I thought, until I had to configure a new load-balancer from a second-tier vendor. As a first-time user of a new appliance, I found the GUI to be extremely helpful. GUIs provide visual cues and use conventions that allow you to figure out how to get the device up and running fast with some basic configuration.
GUIs can also help when you’re dealing with a broad range of devices. Some appliances need very little configuration changes after they go live. In these cases – as I learned -- it's better to stick with the GUI initially rather than spending time to learn the CLI syntax. I was hell-bent on using the CLI for this appliance even though it was costing me time. However, upon reflection, doing initial configuration via the CLI was inefficient and a bad choice for the particular use case.
GUIs don’t scale
So I’ve given the GUI its dues, but the sad fact is that GUIs have quite a few downsides. Using GUIs beyond initial installation is impractical because they're inefficient over the lifetime of a network device, and that inefficiency grows as you deploy more and more GUI-based devices. All engineering involves tradeoffs. When you use a GUI, you are trading first-time deployment benefits for a long list of operational challenges. Let's examine the GUI's downsides:
So we know that a GUI is a great option for first-time deployments and we've examined how the CLI is useful for almost all other use cases. So which do we choose? I say we choose both.
Why should the use of the GUI on day one prevent me from using the CLI later in the appliance's lifetime? The heart of this issue is that engineers cannot easily migrate from the GUI to the CLI, because he or she cannot see the results of GUI changes in the CLI output.
Every GUI should have a "teach-me" mode that shows the user the CLI
command equivalent of every GUI change they make in real time. When
engineers are finished using the GUI, they should be able to see the
full CLI configuration on the screen. The interface should highlight the
CLI configuration lines that were changed or created in the current GUI
session, and which lines differ from the factory configuration.
Ultimately, GUIs are hurting the efficiency of network engineers because they trap the user into a single configuration method. GUI designers need to show a clear link between the GUI and CLI configuration steps. Doing this will enable engineers to bootstrap an unfamiliar device while teaching them the CLI commands needed to document and template the configuration. Only when engineers have a text-based configuration template can they start investigating the benefits of network automation.
Real engineers use the CLI or an API, or so I thought, until I had to configure a new load-balancer from a second-tier vendor. As a first-time user of a new appliance, I found the GUI to be extremely helpful. GUIs provide visual cues and use conventions that allow you to figure out how to get the device up and running fast with some basic configuration.
GUIs can also help when you’re dealing with a broad range of devices. Some appliances need very little configuration changes after they go live. In these cases – as I learned -- it's better to stick with the GUI initially rather than spending time to learn the CLI syntax. I was hell-bent on using the CLI for this appliance even though it was costing me time. However, upon reflection, doing initial configuration via the CLI was inefficient and a bad choice for the particular use case.
GUIs don’t scale
So I’ve given the GUI its dues, but the sad fact is that GUIs have quite a few downsides. Using GUIs beyond initial installation is impractical because they're inefficient over the lifetime of a network device, and that inefficiency grows as you deploy more and more GUI-based devices. All engineering involves tradeoffs. When you use a GUI, you are trading first-time deployment benefits for a long list of operational challenges. Let's examine the GUI's downsides:
- Operations - It's quite common when troubleshooting site-to-site VPN issues for both users to send each other their network configurations, to check if the parameters match. If this happens, you can take screenshots to record your config, but that's a really ugly solution.
- Audit - It's not that hard to write network standards which relate to a GUI, but how do you know if you're compliant with your own policy? The same applies for firewall rule-base audits where you need to painfully extract data from a GUI. Not cool.
- Automation - Okay, okay, it is technically possible to automate GUI operations, but you'd have to really hate yourself to do that. A CLI is an absolute necessity for automation, and a proper API would be even better.
- Change planning - You can’t write a decent change plan for a GUI. One option is to write a lightweight but vague change document, which introduces risk, or you could invest serious effort and add screenshots with red arrows showing where to click.
- Documentation -- The same goes for documentation of the configuration. You shouldn't need a ring binder of GIFs to describe the configuration you applied.
So we know that a GUI is a great option for first-time deployments and we've examined how the CLI is useful for almost all other use cases. So which do we choose? I say we choose both.
Why should the use of the GUI on day one prevent me from using the CLI later in the appliance's lifetime? The heart of this issue is that engineers cannot easily migrate from the GUI to the CLI, because he or she cannot see the results of GUI changes in the CLI output.
(Image: geralt/Pixabay)
Ultimately, GUIs are hurting the efficiency of network engineers because they trap the user into a single configuration method. GUI designers need to show a clear link between the GUI and CLI configuration steps. Doing this will enable engineers to bootstrap an unfamiliar device while teaching them the CLI commands needed to document and template the configuration. Only when engineers have a text-based configuration template can they start investigating the benefits of network automation.
