Somewhere in a land a long time ago, there was this steel factory in the heartland of Pennsylvania. In this steel factory there was a bulletin board on a factory floor room, and on the board were two large posters. The first poster was a reminder of the upcoming layoffs on Friday with procedures for filing paper work and such. The other poster was an announcement of the new IBM mainframe computer that was arriving that week. This new marvel of modern technology just happened to be arriving on that same Friday. The IBM poster encouraged employees to gather and witness this historic event, and that they did. So when Friday rolled around, the poor IBM’rs with their blue suites and dark ties were meet with harsh resentment. The factory floor workers harassed them unmercifully, and in some cases they were actually spat on. I take it you see the irony of the poor steel workers assumed correlation between the new computer and the layoffs. It’s easy to see now that the new “computers” had nothing to do with the layoff… Or is it?
My first real experience with this debate actually occurred around 1987 when I created my first startup. A friend of mine and I had created an automation tool called Sybridge. This product was designed to help operators automate the mundane tasks they needed to perform throughout the day. Back in the day, computer operators working with large IBM mainframes had to enter all sorts of rote command sequences to perform their daily tasks. In 1987, the only programming interface for operators and system administrators was a “green” screen terminal. My friend and I came up with a clever way to screen scrape these terminals allowing operators and systems administrators to create “Rexx” scripts to automate these tasks. For example, back then the only way to enter a problem ticket into a problem management system was to manually enter the data into one of those unforgiving “green” screen monsters. With our Sybridge product, we could capture an online transaction (e.g., CICS transaction) and automatically enter the information into the problem database. Great idea, right? Actually, we spent a lot of time and money doing market analysis on the fear perception that operators might not think this was a great idea. At that time there was a big debate going on about whether automation products would replace humans. However, by the turn of that decade automated operations products were a ubiquitous main stay in almost every fortune 5000 enterprise IT shops. In fact, most of the “good” operators became automation analysts and scripting freaks. The operational productivity of almost every enterprise running IBM mainframes increased tremendously. At least until distributed computing snuck it’s way into the data center.
So I had to chuckle the other night when this same subject of infrastructure automation and people losing jobs came up at the Seattle Cloud Camp. During one of the breakout sessions about Opscamp, a lengthy discussion came about regarding infrastructure automation products like Chef and Puppet and the idea that such products might replace system administrators. Ironically, I was able to use an antidotal example from a conversation I had just a few weeks prior with a friend of mine. The discussion I had was about managing automation products for a large Fortune 1000 company. This friend of mine was a systems administrator who managed a number of proprietary IT management products. The conversation started by him asking me if I could recommend any open source products as replacements for the proprietary ones. He was currently using some of the larger vendor (Big Four) type products and was thinking about a change. I gave him my usual suspects, a list of my favorite operations tools. Then he said “Yeah, but management doesn’t feel comfortable with open sources.” At this point, I lost it. I told him, “Enough with the open source and management. It’s not about open sources versus proprietary, it’s about top line value.” I told him. Then I said, “You have to ask what tools allow you to effect the business top line value for your company?” I had guessed that he spent at least 60% of his day working on the tools trying to fix them and make them work effectively, and less than 40% of his time providing real business value from the tools for his company. He said “John, you are wrong… I spend 80% of my time working on the tool and less than 20% of my time providing value.” That’s what you need to tell management, not OSS vs non-OSS.
The bottom line is that in my 30 years of working in this IT muck, I have never seen an example where automation eliminated valued employees. Automation, however, can be a used as an opportunity to clean up some dead weight. Automation, more often than not, makes good employees better and flushes out the bad ones. Therefore, as these topics of automated infrastructure, infrastructure as code, agile operations, DevSecOps slip into the IT lexicon, we all need to be aware that good system administrators will typically agree that automation does not replace humans, whereas bad system administrators will beg to differ.