Do GUIs really make things simpler?

I was at a technical breakout at a Netapp partner event, and heard a question from an SE (from another partner) that implied that most IT folks don’t have the chops for managing/deploying their environment without using GUIs and wizards.  He postulated that in order to further simplify concepts around complex infrastructure, most admins (especially in small-to-medium enterprises) need the wizard-driven spoon-feeding that GUIs provide so they can get back to the business of doing what they normally do…which is typically putting out all the fires they suffer from on a daily basis.

Ironically, you can trace many of the aforementioned daily fires directly to the use of those GUIs!  Notice I used the term “spoon-feeding” before, that was purposeful- GUIs used to deploy and configure resources (by engineers and not consumers) are just like SUGAR.  It’s sweet going down but you’re going to pay for that in many ways later.

Why is that?

When you use a GUI, Wizard, (or even a non-idempotent script) to deploy something like a VM, server, OS, APP, or even a VLAN, the next time you deploy one you are essentially attempting to rebuild a snowflake with no reference to the original.  This introduces all sorts of unpredictable inconsistencies into the environment, which ultimately results in faults.  Also, testing your GUI-based deployment on a test instance beforehand won’t guarantee you won’t have problems later, since you- the Gui/wizard user – are the most unpredictable component of the deployment, and can’t even guarantee that the test instance matched what you’ll end up with in production.

What’s even worse is that the whole idea of using a deployment wizard implies that you don’t need to know how your [insert tech here] fundamentally works in order to get it deployed.  THIS IS WRONG IS SO MANY WAYS.   How will you know if the [insert tech here] is optimized for your environment?  ..that the configuration the wizard chose won’t cause performance or availability issues down the road? ..that you won’t get boxed into a configuration that limits your flexibility later?   I mean, how can you call yourself an architect/engineer/administrator if you don’t actually LEARN the details of the system you’re going to architect/engineer/administer?

If you decide to use a tool like Puppet or Chef, with which you declare what your [insert tech here] should look like, you MUST by definition know how that technology fundamentally works, at least to some point, right?  You have make all of your choices up front, in the recipe file for instance, and this forces you to understand the available configuration options, etc, and also allows you to apply that configuration to a test instance FIRST, prior to production deployment.  Go try THAT with wizard-based deployment!

Of course, this is HARDER and it’s MORE WORK.  Up front, at least. It also requires research and knowledge.  You need to learn how the configuration/automation tools work.  It implies testing, which many don’t believe they have the time for (but somehow always find the time to fix stuff when it goes down).  So yes, the first time you do something this way, it WILL take longer.  The first time.  After that, the things you do most often become more and more trivial, and they’re done RIGHT, consistently.  The daily fires start turning into weekly and perhaps monthly fires.  Life starts getting more enjoyable.

And YES…this smacks of “DevOps”.  I’m not talking about this from a development or even an enterprise perspective though.  I’m talking about all of those small-medium sized businesses who have 1-2 IT folks who run the show, who are always running around with their hair on fire.  I’ve worked with those people for over 20 years and I feel awful at how many personal weekends and nights they lose because stuff is down.

I like to think of it this way: Would you drive on a suspension bridge that was architected and engineered by a gui-driven wizard, with the architect flying through screen by screen guessing if the default choice in every screen is “ok for now” and clicking “next”?  Or would you feel better knowing that an architect designed that bridge meticulously with great forethought using knowledge of bridges and physics in general, and the engineers thoughtfully built that bridge using the plans but also the knowledge of best practices applied to the specific environment? 

Don’t we as IT infrastructure architects and engineers owe it to our employers and our teammates to apply the same rigor to our work?