On PowerShell

I use PowerShell a lot and I write about using it to solve problems quite frequently. The fact that I can extending Powershell by interfacing with the .NET Framework or making a COM/COM+ object call means I can do just about anything I need to do in order to manage a Windows system. As a result, I consider PowerShell one of my most powerful tools.

However (you knew there was going to be a however), PowerShell is one tool among many. If you are a smart IT pro, you build your toolbox with the tools that are most appropriate for you. Yes, you take into account where the industry is as well as what your current job(s)/client(s) use. Sometimes that means you choose a tool other than PowerShell. To some, though, that sounds of blasphemy. It shouldn’t be. If you’re a senior IT professional, you should be amenable to finding the right tool for the job, even if it’s not the one you like the most. If you’re at an architect level, you had better be prepared to recommend a technology that is the best fit, not the best liked (by you).

When I think in these terms, it means I don’t build Windows system administration tools with Perl any longer. Unfortunately, even though ActiveState still has a very functional version, Perl has faded greatly from view on the Windows side. Granted, it was never very bright, but there were some big name proponents and it gave a whole lot of functionality not available in VBscript/Cscript/Jscript. That’s why some enterprise shops turned to it. With PowerShell, the functionality provided by Perl on Windows systems, the functionality missing from earlier Microsoft scripting languages, is present. So PowerShell will usually make more sense.

I said usually. I don’t automatically select PowerShell because it is the recommended standard by Microsoft. What clients am I running on? What other languages am I using? For instance, if I’m a heavy Python shop, that can be used to manage Windows systems. It may be more cost effective to write in Python than in PowerShell. If I have linux and Mac OS X platforms, I’m likely not using PowerShell. It’s all about the right tool for the job. And the right tool has more considerations than what a particular company recommends.

On Automation

I’m a big fan of automation. I’ve been in IT for 27 years now. One unchanging rule during that time is there is always more to do than there is time to do it. Automation helps close that gap. And when I can automate something, I can do more than peers who can’t. That gives me a competitive advantage. So, three cheers for automation. 

However, the reality is that a lot of administration is still manual. It may sound clever to say that if it’s not automat-able it’s not something you want a part of or that you’re not a player in some space because you don’t automate. But that’s not reality. 

For instance, people can choose to use the cloud and not automate. One reason that the cloud was advertised in the first place was to reduce on-premise costs. You could move to cloud servers and shutdown your costly datacenter and save. You didn’t have to change your day-to-day activities and you would still likely save. That’s not always true, as some startups have shown the math of switching to their own servers when reaching a certain capacity point. But that’s not the point. The point is you should be able to use the cloud even if you aren’t going to automate. 

It may not be as efficient or as cost-effective, but it still should be doable. There may be other business drivers that prevent IT from embracing automation. In the real world, that happens. It happens a lot. There are a finite number of resources. And if business determines that you as a resource would be better spent building out something new rather than automating something existing, then you are building something new. That’s reality. 

So when I hear about a new technology like Nano, I can like it without jumping on the automation bandwagon. Look, you just told me it’s compartmentalized and there’s a lot of surface area removed, even when compared to Windows Server Core. From a security perspective, I am doing a happy dance. I agree that automation makes it better. But just because your vision is automation, automation, automation, doesn’t mean it is everyone’s. And when there are other factors to consider, they may be right for what they are trying to do.

“A good DBA is a lazy DBA”

I’m borrowing from Andy Leonard (blog | twitter) who says all the time, “Good engineers are lazy.”

If you’re thinking, “Why would I want (to be) a lazy DBA?” let me explain. There’s a lot to be said for hard work. However, have you ever seen someone who is always busy but seems to get very little done? Hard work, in and of itself, isn’t the goal. The goal is to get things done. This is where laziness comes in.

If I have to repeat a task, I should look at automating it. I don’t want to have to repeat those steps each time. I want to be lazy. For instance, as an operational person, there are a lot of things I need to review within my production environment on a periodic basis to ensure my systems are running as they should. Case in point: ensuring the SQL Server drives don’t run out of free space. This is something that I should monitor regularly (daily).  There are different ways I could handle this:

  • I could log on to each server and check each drive.
  • I could use a tool like TreeSize to hit the drives one by one.
  • I could automate the checks which results in a report in my inbox.

I prefer the last option. If I’m smart, I’ll even schedule it to run so it’s ready for me when I get in each morning. But why stop there? I could not only automate gathering the data, but also automate some of the analysis. Let’s say I set thresholds and the automation bubbles up anything crossing a threshold to the top of my report, meaning the most important data gets seen first. I don’t want to just be lazy, I want to be very lazy. By being this lazy and automating, I free up the one resource I can never get more of: time.

What can you automate? Anything and everything you can successfully automate frees up time for you to spend tackling other things. The more your organization sees and understands that you do, the more valuable you are. If you are in IT but don’t happen to be a DBA, this is still a solid approach. Let me generalize and say being a lazy IT pro is being a good IT pro.