At a recent technical partner event, a software engineer in the audience posed a question that illuminated the fact that many IT folks still rely heavily on Graphical User Interfaces (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 the constant influx of 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. GUIs used to deploy and configure resources (by engineers and not consumers) are like sugar, sweet going down but you’re going to pay for it later in many ways.
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, it is important to recognize that testing your GUI-based deployment beforehand won’t guarantee you won’t have problems later, since you, the GUI/wizard user, are the most unpredictable component of the deployment. There is unfortunately no guarantee that the test instance matched what you’ll end up with in production.
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 deploy it. This creates a series of challenges. How will you know if the [insert tech here] is optimized for your environment? Or that the configuration the wizard won’t cause performance or availability issues down the road? Or that you won’t get boxed into a configuration that limits your flexibility later?
While the wizard may be tempting, it is absolutely critical to learn the details of the system you are going to administer before any deployment wizard comes into play.
For example, 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. You have make all of your choices up front, and this forces you to understand the available configuration options and also allows you to apply that configuration to a test instance, prior to production deployment.
Of course, this is harder and it requires more work up front. It also requires research and knowledge. You need to learn how the configuration/automation tools work, and do the testing. Remember, if you feel you don’t have time for testing, think about how it actually saves you even more time down the road (as you won’t have issues to fix). So, make no mistake. The first time you do something this way, it will take longer. But soon comes the reward because as things are done right, they become much easier to manage. The daily fires start turning into weekly and perhaps monthly fires. Life starts getting more enjoyable.
And yes, this smacks of “DevOps.” Not from a development or even an enterprise perspective though. In this case, it is about all those small-medium sized businesses who have 1-2 IT folks who run the show, who are the warriors constantly on the front lines of a difficult and time consuming battle.
Think of it this way. Would you drive on a suspension bridge if it the architect and engineer relied on a GUI-driven wizard and opted for the default choice in every instance hoping that would be “ok for now?” Or, would you rather the architect design the bridge meticulously with great forethought using knowledge of bridges and physics in general? And wouldn’t you feel safer and more confident if the engineers then thoughtfully built that bridge using the designs as well as their knowledge of best practices applied to the specific environment?
Don’t let GUIs and deployment wizards lead you down a potentially dangerous path, or be enticed by that manufacturer that insists their deployment GUIs are a primary benefit. By investing some time and energy upfront, IT infrastructure architects and engineers will not only provide a far greater service to our organizations and teammates, but be more successful in every way going forward.
It is important to remember that help is available and that you do not need to go it alone. At Red8, we help many customers facing this very challenge, with support and guidance as needed. If you have questions or are not sure where to begin, please reach out and we are happy to discuss your unique situation.
