I rarely write about my life as a consultant in a direct format. While most of it is confidential in nature, what little is left works its way into blog post ideas that I end up writing anyway. It’s usually a win-win. In this case, however, I wanted to talk about using a variety of software tools from the perspective of someone who visits a multitude of environments. Perhaps my rambling includes some wisdom, but at the very least I want to illustrate why I’ve come to rarely rely on 3rd party tools – such as PowerGUI – for many tasks. Let’s dive in.

Availability of Tools

When I worked on the client side of things I had a static workstation that was loaded with all sorts of helpful tools. Things like RVTools, SecureCRT, PowerGUI, vendor applications, and the like. They were nice to have and often solved my day-to-day problems in an efficient and inexpensive way. I also had the luxury of being an empowered administrator of the system I managed – often a Domain Admin for most forests – and knew exactly where I could and could not linger.

In stark contrast, client environments are often highly confidential and safeguarded with miles of red tape against non-corporate owned equipment. It’s almost a given that anything I own – personally or via my employer – will not be allowed to touch any piece of software or hardware in the average client environment. It causes too many headaches with compliance rule sets like Sarbanes-Oxley (SOX) and, frankly, some folks just don’t trust me because they don’t know me. I’m OK with that and respect their position.

This means that I’ve come to rely on whatever tools are universally available. Let’s take PowerShell for example. I have an entire library of scripts that I’ve written over the past several years. More often than not I end up using the vSphere Client or ESXi Shell instead because I can’t get to my scripts. If it’s a highly repetitious task I may just re-create a script by hand, but more often than not, it’s not worth the effort.

[symple_box color=”yellow” text_align=”left” width=”100%” float=”none”]
Takeaway: Learn what tools come native with a vendor application or product and master them. Don’t hobble yourself by relying on fancy tools to get the job done.
[/symple_box]

Access Limitations

In a similar vein to compliance restrictions, there are some cases where you are only able to bring in what’s in your head. This often means no Internet access due to rogue wireless sniffers (hot spot finders) or being in a location that is physically not able to get a 3G/4G signal. So, how do you get software installed or updated? Hopefully you brought the necessary files on a USB stick (and can find someone with authorization to use the USB stick).

I consider Google a rather awesome software tool and use it all the time. I would be hard pressed to find anyone who can say the opposite with a straight face. I’m not a dictionary, and there are many things I put into this blog so that I purposely don’t have to remember anymore. That’s the point, right? 🙂

[symple_box color=”yellow” text_align=”left” width=”100%” float=”none”]
Takeaway: Don’t take Internet access for granted. Come prepared.
[/symple_box]

Time Restrictions

The use of software tools are great for automation. I lean heavily on automation in my day-to-day work, especially when I was on the customer side. A few hours of code here and there can save days of my time over the course of a year. But that’s sort of the crux, isn’t it – how many consulting engagements take years? It depends on what you do.

I’ve found that most ad-hoc tasks are not worth automating unless I can access a pre-written script and recycle it for the task at hand. Try to estimate how long it’ll take to do something by hand. Then compare that to writing a script or bit of code. Unless the automated method is decently faster, don’t bother – time is a luxury for most tasks, especially if what you’re working on is in the project’s critical path. There are so many snags to hit while trying to automate an unknown environment that it’s usually not worth it. When it’s your environment and you know where the skeletons hide, it’s significantly easier to code around them.

[symple_box color=”yellow” text_align=”left” width=”100%” float=”none”]
Takeaway: Have scripts in your toolbox, but know how to work around them in real time.
[/symple_box]

Thoughts

This post has been in draft for quite some time as I continued to add notes and thoughts over time. I recall saying something about a vSphere CLI on Twitter a while back and many folks had no idea why I wouldn’t just use (fill in the blank of any 3rd party software here). Trust me, I would! But it’s often a luxury to do so. 🙂