April 18, 2017
Automation tools are going through a renaissance...and an explosion. How many is enough?
How many automation tools does it take to...
So, we are big fans of automation around here, since most of us have been IT professionals and have felt keenly the fact that humans don't scale at the same speed that systems proliferate. But, we are not fans of unconstrained automation, at least not in the enterprise data center and cloud. Rather, we have so far seen that that the enterprise benefits best when some limits are placed on how staff build and use automation in IT operations.
Maybe 10 years ago, we wrote a blog on the topic, "Does it really take 100 tools to secure the data center?" We have since discussed the same idea with respect to management tools: how many management tools does IT need to run the data center (or, should we revisit it now, data center and/or cloud)? The answer to the latter question seemed to be, for most of the IT folks we spoke with during many and varied research benchmarks, either "Not as many as I have, I have too much shelfware and overlap already" or "Just a couple more, for these new things we are doing!" or, frighteningly, both! We are seeing a similar situation in automation now.
The blog linked above touches on our chief concerns with doing automation well, given how much is necessary. The need for change management and code management are chief among those concerns, followed by the need for code standards and, germane here, tool standards.
Tool standards revolve around function at the low level (what tools can do) and around the automation tools portfolio at the high level. It is important to think of it as a portfolio, to emphasize the idea that the tools do not exist in a vacuum. With each tool added, costs accrues for acquiring, installing, and maintaining it, always non-zero, and for some tools considerable.
More importantly, in our view, there is also the associated cost of ensuring that all the people that need to, know how to use the tool. Nearly any IT organization has some level of cross-covering among staff. The more fractured the tool set, the harder it gets to make sure that for every tool, multiple people are expert enough with it to cover for each other as needed.
Cruel as it is, I always fall back on the "What happens if Chris gets hit by a bus?" trope in driving the point home (and I speak as someone who was very nearly struck by a bus when I was starting out in IT in Baltimore). You should never put the organization in the position of having only one person who knows how to work an automation tool on which production operations depend. So, admins and integrators should not be adding tools willy-nilly as they move from task to task and project to project.
Automation Tools - The More, the Merrier?
But, there are pressures to add more tools, all the time. There is that sense, alluded to above, that a new kind of activity needs a new tool to manage it. Sometimes this is true, but usually not -- usually, one or more tool already in the portfolio can be made to serve. There is also an incentive to adopt a new tool if you can find ready-made scripts for managing an environment based on that tool. Or if it is the only tool the maker of the system officially supports.
However, the driver for expanding the automation toolset we are hearing most so far in this year's benchmark interviews is more human-centered than any of these: we want to allow people to bring their preferred tools with them to make the workplace more attractive. While this may lead to short term satisfaction, it will lead to longer term chaos without some countervailing (policy-driven) pressure to prune the set down at the same time, so that it does not have open-ended growth. As the figure above shows, even a small sampling of tools relevant to the devops space involves a plethora of overlapping solutions. (A recent article I saw trumpeted the "48 Best" automation tools, suggesting myriad less worthy solutions not selected for inclusion.)
In adapting to ever-greater amounts of automation in IT operations, IT staff need to be ready to expand their toolsets, but also need to keep in mind that too much of a good thing is no good at all, and so plan to weed tools out at the same time they add new ones in. This will necessarily mean converting some scripts or jobs to a new language/tool, but in the long run that is going to happen with a lot of jobs anyway. It's better to go at it planfully than to be surprised after someone leaves, and leaves behind suddenly misbehaving, obscure jobs automated in obscurer languages.