A Command Line Interface (CLI) allows users to write commands or scripts in a console or (remote) terminal. Commands respond with a text-based representation. Some example in the vSphere environments, are the commands executed with the ESXi shell or thought the ESXi SSH service. But also, all the scripting languages are another example of CLI, like, for example, PowerCLI.
Note it’s also possible build semi-graphical user interfaces, for example in ESXi consider the Direct Console UI (DCUI).
A Graphic User Interface (GUI) is a graphical representation in which the users can interact with software or devices through graphical objects, like windows, buttons, scrollbars, icons, using a graphical display and a mouse (or a touch device), or also using remote graphical protocols (like RDP or X-Window).
Usually, it is an easy-to-use interface good for novice users, because it’s intuitive, easy to learn and reduces cognitive load. But can be good also for users that need to do simple tasks or needs high-level information.
Typical GUI interfaces can be based on specific graphical programs in the form of a “thick” programs (for example the legacy vSphere Client for Windows based on C#), or based on a web application (for example the vSphere Web Client or the new HTML5 vSphere Client).
In several cases, a user can choose to use the CLI or GUI, in other cases, for example for some specific tasks, maybe it’s possible to use only one type of interface.
Also note that there are other types of interfaces like the API, but in this case, we cannot really consider a user interface. And sometimes the boundary it’s not so clear and easy to be defined, for example, several admins use the RESTful API not as a development tools, but much like as an automation tool, instead of CLI (or complementary to CLI).
But what are the differences between the two approaches and which are the pro and the cons of each of them?
The following table illustrates which interface has the advantage in certain categories and why:
| Topic | CLI | GUI |
|---|---|---|
| Ease to use | To be productive you need a good knowledge and familiarity with commands and their syntax. | GUI is much more visually and could be intuitive, for this reason, could be simple for new users or novice uses.
With the GUI it’s possible also implement wizard to make specific task much easier and assisted. |
| Speed of execution | If you already know the right command and syntax, CLI could be really fast to be executed. | Also if you know the right position on the menu tree, probably you need to access multiple level and click several times before complete a task. Wizard-based task can improve the usability, but makes the entire process much slower, due the multiple iterations. |
| Repeatable | CLI is repeatable and permit multiple executions, for example, to make the same tasks on more systems. | To repeat the same task using the GUI you need to navigate the same menu and repeat the same operations multiple time. |
| Language | CLI can used both as a language or as a documentation. Also usually it does not depends by the different localizations. | GUI aspects can vary, for example, due to localization.
GUI tasks can be documented with snapshots, but it’s less effective than using CLI commands. |
| Remote management | Remote text-based protocols, like SSH, could be very bandwidth effective. | Remote graphical based protocols, like RDP or ICA, require usually more bandwidth.
Web-based application can be more bandwidth “friendly”. |
| Portability and multi-platform | CLI could be multi-platform depending on if you have the remote terminal client or the right interpreter for multiple systems. | Thick graphical based applications usually are not multi-platform, unless they are executed remotely. Web-based application, by design, could be more cross-platform. |
| Control | CLI provide a good control on what it’s executed (if you know how execute it). | GUI can better assist and drive the user. |
| Completeness | Depending by the solutions, in some cases the GUI may call the CLI commands that is much complete. | Depending by the solutions, the GUI and the CLI may be complementary.
But the GUI can become a single pane of glass. |
| Resources | Usually the command line tools require less system resources than GUI. | A full GUI client may require more system resources because of the elements that require loading, such as icons and fonts. Also, a web-based application may consume more resources compared to CLI. |
| Requirements | CLI just requires a keyboard and a “terminal” (local or remote) access. | GUI requires keyboard and mouse and a graphical device. |
| Accuracy | CLI is more accurate and precise, just because command behaviour is usually predictable.
But of course, mistyping could result in complete chaos. |
GUI may have strange behaviours, for example in web interfaces sometimes a page refresh could be needed. |
| Scripting and automation | Using CLI is easy build script and automate process. Most CLI are just extension of scripting languages. | Creating scripts using a GUI maybe be simple, depending by the automation level provided by the GUI. But it most cases there is nothing. |
| Diversity and consistency | CLI is usually much “stable” during the years. Also, if a new command may be introduced, the original command almost always remain. | GUI may change due to technology changes of new user devices. |
Now let’s descent all those aspects to the specific case of VMware vSphere, using those examples:
- For CLI: I just consider the local CLI (ESXi and VCSA shells) and PowerCLI, but of course, there are several others possible CLI, including the vMA and different other scripting languages extensions.
- For GUI: I consider mostly the web clients, but for vSphere versions previous 6.5 there are still some people that are using the legacy vSphere Client for Windows.
| Topic | CLI | GUI |
|---|---|---|
| Ease to use | CLI initially it’s not easy, but more you are using it more become easiest.
For PowerCLI there is also the difficult to know the language itself, to better be productive. |
All vSphere web interfaces are intuitive, especially for new users or novice uses.
Also, the different wizards and helps (like the getting started page) may help you to do your first steps. |
| Speed of execution | CLI is quite fast. Also for PowerCLI, after that PowerShell has been loaded, the execution is fast. | The promise of the vSphere web was to be more faster than the legacy vSphere Client, but for small environment it’s not so true.
And compared to CLI executions, it’s usually slower. |
| Repeatable | CLI is repeatable and permit multiple executions, for example, to make the same tasks on more systems. | To repeat the same task using the GUI you need to navigate the same menu, and repeat the same operations multiple time.
At least, for failed task, with the web clients is possible resume them easily. |
| Language | CLI can used both as a language or as a documentation tool. It’s repeatable but also consistent across different vSphere version (at least starting from v5). | The UI vary too much across the different web client (and also compared with the old legacy client).
GUI tasks can be documented with snapshots, but it’s less effective than using CLI commands. |
| Remote management | Using SSH you can access the ESXi or the VCSA shell. But you can use other solutions like the RCLI.
Or better use PowerCLI that can manage a remote vSphere environment. |
Both the web and the legacy vSphere clients are designed for the remote management, but latency (and bandwidth) may limit their usage. |
| Portability and multi-platform | Local ESXi or VCSA CLI can be access remotely from different clients.
For PowerCLI, finally, the version 10.0.0 provide multi-platform support. |
The legacy vSphere Client was only for Windows. But the web clients are multi-platform and multi-browser. |
| Control | CLI provide a better control on what it’s executed (if you know how execute it). | GUI can better assist and wizard can drive the user for new tasks. |
| Completeness | Actually you cannot perform every admin task from the CLI, or at least not only with one single CLI. | The new HTML5 vSphere Client is still not 100% complete. |
| Resources | Usually the CLI require less system resources on the client than GUI.
But on ESXi or VCSA it’s not clear if there is a real difference between CLI and GUI. |
The legacy vSphere Client was a huge client resources consumer.
But also the web clients require more resources compared to the CLI approach. |
| Requirements | In most cases your requirements are satisfied buy your client. For PowerCLI 10.0.0 you need PowerShell Core. | The legacy vSphere Client required old version of .NET Framework.
The web clients just a compatible browser, but the vSphere Web Client needs also Flash. |
| Accuracy | CLI is more accurate and precise, just because command behaviour is usually predictable, also across different version of vSphere. | GUI may have strange behaviours, for example all the different web clients have different interfaces and not always the same numbers or information. |
| Scripting and automation | Using PowerCLI is really easy build script and automate process. | The different vSphere clients are not suitable to build scripting or automation. |
| Diversity and consistency | CLI is usually much “stable” during the years. The big change was with version 5.0 of vSphere were the local ESXi CLI was completely changed. | All the different vSphere clients have different aspects and sometimes also different behaviours. |
Conclusion
Both CLI and GUI have their advantages and disadvantages, and they are appropriate according to the user requirements, knowledge, skills and use.
The graphic user interface can be more efficiency for new users or users who have to focus on the data visualization; for this reason could be better for operators, although maybe they are accessing other tools, like monitoring tools or cloud management tools.
The command line interface offers more control, precision and repeatability; for this reason could be more powerful for admins, considering also that the vSphere web clients are actually in a “transition” phase with the vSphere Web Client (the only GUI that is actually “complete”) destined to become soon a legacy tool (due to the Flash dependency).
Generically speaking, limiting yourself to graphical user interface maybe be not wise, especially if you have to perform several time the same tasks. The command line interface, can really help you in become more productive but also in building script and make repetitive tasks more controllable and predictable.
But could be is equally unwise to completely ignore the graphical user interfaces because there are situations when using GUI is more productive, for example in data visualization.
Unfortunately, at this time, having a mixed approach with the best of both worlds isn’t easy on VMware vSphere. What will be nice, and increase the adoption of CLI, it’s having the GUI that shows the right commands that can be executed to perform the same task. This will really help to better understand the commands their syntax.
To make an example, use the same approach used by Microsoft System Center or also by the Server Manager, that shows the right PowerShell commands that will be executed.
For the legacy vSphere Client for Windows, there was a nice Flings project (called Onyx), but now for the web clients, there isn’t anything specific.
When there will be only one client (the HTML5 vSphere Client) and also only one type of vCenter Server (the VCSA), maybe will be simpler transform the GUI as a wrapper of the CLI and make this approach more effective. Also with the new version of PowerCLI that it’s finally multi-platform, should be nice if there will be just one main CLI, instead of the plethora of CLI actually available in vSphere (too much languages does not really help in a wide adoption).
