Automation is a very hot topic these days. Actually, that’s probably one of the understatements of the current state of IT. Everywhere you turn, you get some sort of message about how important automation is. Unfortunately, due to the sad state of IT up until “right now”, very few people have been able to devote the cycles necessary to understand automation and the processes automation is supposed to represent.
Back at VMworld US 2016, I was privileged to be a panelist for an Opening Acts panel that had automation and DevOps (although we didn’t even touch DevOps, much to my dismay) as the topics. One of the opening questions was about barriers to automation and I piped up about the fact that many Operations folk are just not versed in programming/scripting skills. I was quickly drown out by others bringing up that process was the biggest barrier to automation within existing IT shops.
I’m going to wholeheartedly disagree with some of my panelists. Even in my current day job, many of our Operations personnel have the processes defined, as per specific industry certifications. Documentation is constantly being updated about these processes and kept relatively up to date. What my Operations team lacks is the programming specific knowledge to interface with all these disparate systems.
Internally, we’ve specifically targeted initiatives to teach (both internally and externally) PowerShell to our Operations personnel. We’ve identified that many of our systems come with PowerShell modules to easily create multifaceted scripts to touch many systems within a single script or line of code. My goal is to get my Operations team up to speed on what I’ve personally done with PowerShell and integration in our automation/orchestration system in Cisco UCS Director. Unfortunately, they have a steep learning curve with some vendors in the infrastructure space.
Why is this? It comes down to some companies feeling that just having a RESTful API as being “good enough” for integrators out there. For those administrators that are learning the ways of programming, a RESTful API call can look a little daunting, considering some of the languages you actually wrap that request into.
I’m going to go back to a presentation I sat through from Zerto back at Tech Field Day 11. The presenter had a many lines of PowerShell code up on the screen (somewhere in the 300+ lines category). I asked the question of whether Zerto had considered wrapping all those Invoke-WebRequest and Invoke-RestMethod calls into their own specific PowerShell cmdlets and I was met with a response that seemed to indicate that maybe they hadn’t considered it.
It’s going to feel like I’m going to be picking on Zerto here, but when you dig into their architecture and what they were specifically trying to show us in that demonstration, nearly all the endpoints they were touching had PowerShell modules available so that all calls could be integrated into a single script. Microsoft Azure has many PowerShell modules for accessing subscription information and provisioning virtual machines; VMware has their PowerCLI modules that could be leveraged for the on-premises virtual machines in which Zerto was trying to replicate out to public cloud resources; AWS even has a subset of either official or user/community created modules for accessing EC2 instances.
The point being, that many of the system administration community is learning how to automate their environments in the form of very human readable cmdlets within PowerShell. If you, as a company working on enabling APIs for your user base, haven’t considering wrapping these up into a much easier format for use, maybe you should. That community is not, and will likely never be, full-fledged integrators. It’s time to start making their lives a little easier by creating better tools that wrap the RESTful APIs up in a more system administrator/beginner scripter-friendly format. I highly suggest to these companies to do so with PowerShell, especially considering the now open source nature of PowerShell.