Quantcast
Channel: Avanade Blog » Virtualization
Viewing all articles
Browse latest Browse all 7

Demise of the Graphical User Interface (GUI)

$
0
0

PowerShell – The Retro User Interface (RUI) for Systems Management in the Elastic Datacenter

I began my IT career in the 1980’s before the advent of Windows (or Macintosh) and Graphical User Interfaces (GUIs). I was proficient with MS-DOS and Netware as well as VMS DCL and UNIX Shell command line interfaces but always found them cumbersome, unintuitive and blatantly cryptic at times.  The advent of GUI-based Operating Systems and System Management consoles made the job of IT Operations and Administration much easier or at least, we thought so. While GUIs are great for doing one-off tasks, they can be a hindrance when we want to perform tasks repetitively, script a sequence of tasks or automate an operational process, workflow or service.  As a former MIS Manager back in the early 90’s, I had UNIX shell wizards (i.e., nerds) that worked for me that lived and breathed the command line interpreter and argued they could write a shell script to doing just about anything I wanted and didn’t need no stinking GUI.

 

GUI vs. RUI

With the approaching release of System Center 2012 suite, Microsoft continues to condense its dependence on GUI-based system management tools with the addition of hundreds of new retro-command line commands based on PowerShell. This “regression” to what I like to call a “Retro User Interface” (or RUI) began with Exchange 2007 and Exchange 2010 and the introduction of the Exchange Management Shell, a management tool based on the command line and built on top of Windows PowerShell. The Exchange Management Shell simply extended PowerShell by adding a few hundred additional Exchange-specific cmdlets. The regression plot thickens when you realize that the Exchange Management Console (i.e., the GUI tool) is built on top of the Exchange Management Shell. Each administrative action performed through the GUI in turn produces a series of Windows PowerShell commands that are then executed.

 

With the release of Windows Server 2008 R2, you may have noticed the PowerShell icon now appears by default in Windows Server 2008 R2 and System Center Virtual Machine Manager 2008 R2 includes 158 PowerShell cmdlets and will increase to over 400 in SCVMM 2012. The SCVMM GUI-based management console is also built on top of PowerShell. And, the current beta release of System Center 2012 suite adds hundreds of new PowerShell cmdlets. In addition, System Center Orchestrator 2012includes a new PowerShell provider to allow Orchestrator to be integrated into scripts and provide a mechanism for remote execution of runbooks.

 

At first glance it appears Microsoft is generously providing us with two separate but equal management tools–GUI Consoles and PowerShell. Whether you like it or not these new PowerShell-based GUI consoles only expose a subset of the management functions that are available through the underlying PowerShell cmdlets. With the release of System Center 2012, many more common management tasks will have to be performed from the command line.

 

Automation

While this focus on PowerShell may seem like Microsoft is regressing, there is a logical explanation for this RUI-based approach. It is the need for datacenter automation and the ability to provide Infrastructure as a Service (IaaS). Its difficult to automate workflows and process around a suite of GUI-only-based management tools. However, if “all” of the commands that can be executed in the GUI have command line equivalents, then it becomes much easier to create scripts that can perform repetitive tasks and orchestrate actions and data exchange between disparate service management systems. The PowerShell Engine is a key component of the Automation Environment within the Windows Management Framework.

 

What This Means for Service Operations

The result of this regression from the GUI to the RUI is that IT operators and administrators can no longer manage their Microsoft-based technology infrastructure without knowing how to use Windows PowerShell. In addition to Microsoft, companies like NetApp are providing collections of PowerShell cmdlets for facilitating integration of their products into Windows environments and management tools. Many of the Microsoft server products have been or will be PowerShell-ized and require effective administrators to be proficient in Windows PowerShell. In addition, the transformation of the physical datacenter to an Elastic Datacenter or private cloud built around Microsoft virtualization, automation and orchestration technologies will be dependent on individuals with PowerShell scripting expertise. So, for old IT consultants like me it’s a return to the old ways (yeah!), but for younger IT professionals weaned on GUI-based management tools there may be a bit more of a learning curve. I like to think of the PowerShell window as the Steampunk User Interface for Systems Management.

 

I interview a couple of Systems Engineering candidates every week for Avanade (and YES we are hiring) and I’ve yet to find one that is well-versed in PowerShell. Here are my suggested steps for becoming proficient in PowerShell. I’m sure I don’t need to state the obvious, but just in case, do NOT attempt these steps in a production environment.

 

  1. Get a good PowerShell Book (See my recommendations below)
  2. Create a Windows Server 2008 R2 VM on your PC, laptop or lab environment and enable the PowerShell ISE feature
  3. Review the tutorials at Learn Scripting
  4. Consider using one of the PowerShell GUIs, editors or development environments – See Tools below
  5. Download and experiment with sample PowerShell scripts
  6. Write your own scripts and build your own repository of useful PowerShell scripts
  7. Share you scripts and develop a reputation as a PowerShell scripter
  8. Update your resume to include your new PowerShell skills

 

Recommend Reading

 

Links

 

Tools


Viewing all articles
Browse latest Browse all 7

Trending Articles