Published on , commented on July 9, 2022
Fallacies of GUI
I love Greg Ferro’s characterization of CLI:
We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.
However, you do know that most devices’ GUI offers nothing more than what CLI does, don’t you? Where’s the catch?
For whatever reason, people find colorful screens full of clickable items less intimidating than a blinking cursor on black background. Makes sense – after all, you can see all the options you have; you can try pulling down things to explore possible values, and commit the changes once you think you enabled the right set of options. Does that make a product easier to use? Probably. Will it result in better-performing product? Hardly.
Have you ever tried to configure OSPF through GUI? How about trying to configure usernames and passwords for individual wireless users? In both cases you’re left with the same options as you’d have in CLI (because most vendors implement GUI as eye candy in front of the CLI or API). If you know how to configure OSPF or RADIUS server, GUI helps you break the language barrier (example: moving from Cisco IOS to Junos), if you don’t know what OSPF is, GUI still won’t save the day ... or it might, if you try clicking all the possible options until you get one that seems to work (expect a few meltdowns on the way if you’re practicing your clicking skills on a live network).
What the casual network admins need are GUI wizards – a tool that helps you achieve a goal while keeping your involvement to a minimum. For example: “I need IP routing between these three boxes. Go do it!” should translate into “Configure OSPF in area 0 on all transit interfaces.” When you see a GUI offering this level of abstraction please let me know. In the meantime, I’m positive that the engineers who have to get a job done quickly prefer using CLI over clickety-click GUI (and I’m not the only one), regardless of whether they have to configure a network device, Linux server, Apache, MySQL, MongoDB or a zillion other products. Why do you think Microsoft invested so heavily in PowerShell?
After all, I think I remember correctly, some product line manager from HP already claim that SDN will cure the world from pesky network engineers.
In the end, everybody is free to use whatever they want to get the job done (CLI or GUI). The problem appears when somebody has the idea that using GUI instead of CLI means cost cut and quick import of know-how.
Personally, I'd put my money on a more generic configuration framework, something like what you can do with ansible on Junos, allowing admins to define their *own* tools and workflows becoming useful long before another "Enterprise Ready!" 8,000lb gorilla turnkey solution can do more than the top 10 workflows of the top 5 customers.
For whatever reason, GUIs tend to have more abstraction than CLI. There is nothing inherent in the interface that suggests that has to be the case, but I think the mindset is different. "I am making this GUI to make it easier, therefore I will think through how to simplify."
Where the GUI just exposes knobs, it is usually built on the same underlying config, so the GUI and CLI will be necessarily the same. But where the GUI provides the abstraction you talk about, that can be powerful.
The question we ought to be asking is if that abstraction is available from the GUI, why not make it available in the CLI as well? I know it is not entirely apples-to-apples, but the point is that there are ways to do it in both.
-Mike Bushong (@mbushong)
Plexxi
That doesn't mean some great tool with a great GUI that takes care of some hard bits won't ever exist. I'm just saying "GUI" doesn't automatically mean "better."
GUI wizards help make sure one doesn't forget to set any important parameters in the first run. Hence, I can be sure my apprentice will configure a PPPoE server without forgetting to set DNS parameters - GUI will not let her click Next before filling out these fields. After doing this a dozen times she will figure out that it's faster to copy&paste CLI config for new deployments which is a nice side benefit.
We use IOS for core routing, but a lot of Mikrotik stuff for access and PE. Mikrotik is surely not suitable for heavy-duty core stuff, but their Windows GUI is a great example of how a useful GUI should be developed.
ASA's on the other hand - the GUI is a poor attempt at making an ASA as friendly as a Checkpoint. The GUI is NOT intuitive, frustrating, and basically nothing more than a Graphic interpreter of CLI commands (you can even turn on the option of looking at the CLI that the GUI is about to enter for you). Most telling is when calling TAC for an ASA, the TAC engineers NEVER use the GUI for analysis and troubleshooting.
I think GUIs are nice and have their place (Windows) but CLI is where the real power is.
Why not EIGRP? How do you know those boxes are in area 0?
If you want to have a simple network that can be configured with a wizard, you have to start with the simplest possible design.
I believe the bigger issue is that if network management is simplified, the cost will drop. No longer will Cisco/CCIE be billable at the current rate. How hard can it be to register all devices to a central system, provide a graphical layout of the environment, and then define routes, ACL, QOS, etc. The answer, job/pay protection (like lawyers).
SDN is seeking to address this. If we can build physical servers and storage, databases, email systems, content management systems, customer relationship management systems, and much more at the click of a button...
Certain assumptions are made, of course, but it's a start.
My 2 cents.
F5 does that (not sure about Junos) and it's absolutely fantastic. Imagine doing that for ACL or FW ruleset.