Friday, March 17, 2017

In Defense of Shadow IT

Spend any measurable amount of time listening to a vendor presentation, and you'll hear undoubtably hear the phrase "Shadow IT." If you're not familiar with the term, it's used to describe a situation in which users circumnavigate corporate or centralized technology teams and solutions in favor of other services, primarily public cloud services.

For example, a user may opt to deploy an application to AWS instead of going through the in-house development and operations channels. Or a developer might spin up some test applications in Google Cloud Platform because her IT organization didn't know their kubernetes from their vmkernels.

Vendors hold up Shadow IT as a perfect example of what's wrong with technology, namely cloud computing, and will happily share with you their solutions intended to stop it.

In the eyes of the vendor, shadow IT is the problem.

In fact, shadow IT is a solution. The real problem is officious, ineffective delivery organizations hellbent on dictating how IT should be consumed. More specifically, the real problem is IT organizations that, instead of listening to the needs of its customers, continue to offer the same catalogue of services from a decade ago.

Oh, you'd forgotten about HoJo? Me, too.
It's the same type of problem that forced Howard Johnson's restaurants to nearly disappear from the map: the problem wasn't that people weren't eating at HoJos, the problem was that HoJos had excruciatingly shitty food. No amount of begging customers to come back will make a difference when your product doesn't directly address their needs.

It's Not Your Customers, It's You

If you work in an organization that views shadow IT as a problem to be addressed, you work in a broken IT organization. Your users aren't the problem; you are. Users don't embrace shadow IT (and really, we shouldn't even call it that anymore, because users don't think to themselves, "I think I'll circumvent my company's IT policies and not use their servers," they think, "I need to get my work done and my company's IT shop can't, or won't, help me."), they embrace creative problem solving when faced with hang-wringing and stonewalling from their internal IT department.

IT exists to enable application delivery in support of the business. And application developers will find a way to deploy their apps no matter how incapable their IT shops may be.

Wednesday, March 8, 2017

How to Get-OverYourself and Learn PowerShell

If you listen to the evangelists, you'd probably think that in 2017, there is only one person who isn't using PowerShell: you. Everyone else not only gets it, but uses it to automate all of their work, including manipulating databases, monitoring systems, interviewing candidates, and filing IPOs. And the simple fact that you don't use it makes you a dinosaur. Frankly, it's amazing that you're even employed.

Luckily, you don't listen to evangelists. They spend too much time on Twitter and not enough time in the trenches.

So let's quit talking about PowerShell like it's the harbinger of change in the technology world. It's a scripting language1. Not the first, not the last, not the best, not the worst. It's not going to change your life. If you're unhappy with your job, learning PowerShell may be a temporary distraction from your unhappiness, but it's not going to change your sentiment with regard to your work.

I'm telling you this because you should have realistic expectations, in general, but specifically with new technology.

Once you've taken a moment to reconsider your opinion of PowerShell as panacea, continue reading.


Now that you've gotten rid of the anxiety surrounding PowerShell, you are ready to see its strengths and weaknesses more clearly. For example, if you're looking to make a simple change to a number of servers, PowerShell is a great tool. If you're looking to deploy patches to a mission-critical database server, you're better off with another solution. PowerShell, like most automation solutions, is ideal for 1:many actions. The work is front-loaded; spend time developing a solution, then use automation to scale that solution out.

This is all to say that you should not consider PowerShell as a foreign language to learn only to remain relevant in IT. You should consider it as a technology that can change how you approach your work, especially when you're managing an infrastructure at scale.

Consider a timely example that we're dealing with in the Microsoft shops of the world: the mass disabling of SMBv1. In Server 2012 and newer, there's a PowerShell cmdlet that can be used to enable and disable SMB on a remote server. And even though you immediately think to yourself, "I can do this in a GPO," I submit to you that PowerShell is a much cleaner way to implement this type of minor change, if for no other reason than you're avoiding GPO hell, which is like .dll hell, but with a GUI.

With PowerShell, you can query AD for a list of computers, filter out the server running 2012 and newer, and invoke a remote cmdlet to disable SMBv1 on as many servers as you'd like, all in one fell swoop2. You don't need to worry about WMI filtering in GPOs, or wondering if your custom method of settings registry values will work on all versions of Windows Server. You just put a few lines of PowerShell together, and go.

The point of this post is not to show you the script itself (although I'll follow this post up with a post that includes the deets, because I oscillate wildly between essays and engineering). The point is that PowerShell really is an amazing chunk of code, and once you get your mind right about why you'd use it, learning PowerShell is fun.

1 - PowerShell MVPs and enthusiasts of all stripes just rolled their eyes so hard they can see their own brain stem.
2 - Your high school English teacher would really appreciate it if you'd read Macbeth, really read it, not just skim the first act and confuse it with Hamlet, which you should also read. Thanks.