Speeding Transition to the Cloud: Automation

Moving to the cloud gives many companies an opportunity to review and improve many of their operational practices. In addition to developing a comprehensive cloud strategy, as we discussed in our last article, there are several other steps that can help speed the transition to the cloud and becoming a digital business. Front and center in this effort is IT automation. If done correctly, automation creates many differentiated advantages for a company. Read on for the “What, Why, and How” of IT automation with a bonus of things to avoid when it comes to automation.

What to automate?

Everything! (almost): With automation, everything should be a candidate. Many times the best strategy is to go for the low hanging fruit or the “quick win.” This gets some tick marks in the win column to justify the larger effort to evaluate all processes for automation. In some cases, the larger and more complicated processes offer the best payback for the investment of time. Also worth noting is that automation isn’t an “all or nothing” proposition. A twelve-step process with one human decision point could be automated down to that one step while providing most of the larger benefits of automation.

Why automate?

More responsiveness: Let’s face it, automated systems are much more responsive than people. People need to be prompted to act, make the decision, and then act on it. This builds a lot of lag into the response. For customer issues, problem tickets, or capacity issues, this can mean impact to the bottom line. I’m not sure I know anyone chomping at the bit to build that Excel report you’re asking for either.

Less error-prone and mundane: Speaking of Excel reports, they’re probably wrong. One of the biggest problems with human-driven manual work is that it’s error-prone. People make mistakes, especially on tasks they don’t like or think are repetitive and boring. This creates a negative feedback loop as the originator has to re-do the work that they already hated doing the first time around. The good news is that working on automating a task is generally challenging and interesting work that is highly preferred to the original task.

How to automate?

Standardize on a platform: If you’ve read this far, you’re probably already convinced that automation is a desirable and necessary part of your IT toolbox. You might say I’m preaching to the choir. But, how would a choir sound if everyone was singing a different song? Terrible. So too, automation can become a minefield of individual efforts mired in outdated code and stealth IT utilities. It’s imperative that automation strategy be coordinated and centralized. Platforms like Puppet and Chef come to mind first, but it can be as basic as choosing a standard scripting language, code repository, and “automation server.”

Bring automation into the fold: If you’re not already, you need to treat automation as a critical part of your business. Normalization brings automation scripts and systems out of the shadows of stealth IT and legitimizes it. Automation systems should be redundant and highly available, not a cron job running on someone’s laptop. In case I’m not being clear, I mean spending money. Automation saves companies untold amounts of money and time, so investing in those systems is worth it.

Reward automation: We’ve all been there when the CEO sends out congratulations for a big sales win for the quarter, while some guy in IT saves the company a thousand dollars a week -forever- and not a word is spoken. Automation successes need to be monetized, socialized, and rewarded. Recognition goes a long way. As the old saying goes, you incentivize the behavior you want more of.

What not to automate?

Requires nuanced or complicated decision making: Predictably, when companies get excited about automation, it gets harder and harder to say no. One of the first stumbling blocks is attempting to automate a process that is very complicated or requires making decisions based on vague information. It may be that the process could be simplified or that the problem could be quantified better, but that can’t be achieved by making the automation more complicated. Don’t use automation to try and solve upstream problems.

High impact decisions: Did I mention DR failover? There are many examples of processes that could be automated but represent a significant impact to the company. A one-way DR failover scenario might require days of manpower to revert back to the production datacenter and should in most cases have a person pressing the button. In general, most decisions that are one-way or difficult to roll back should be done manually. In 2014, one company’s automation systems reformatted the C: drive of every server under maintenance including the automation system! Ouch.

If automation spoils your upgrade path: While more rare, in some cases heavily automating into an existing system will ruin your upgrade path. Every patch will require reworking and rebuilding the automation tools and the ing that goes with it. Whether you automate or not will depend largely on the patch schedule and effort necessary to keep current. This can be limited on open source projects by submitting your automation scripts to become a part of the supported project.

Covering root causes: Automation as the mega-Band-Aid. We’ve all seen it, and probably done it; Creating that script that reboots that service when the RAM gets high, or the threads run long, or the ephemeral ports fill up. These scripts are good in the short term but ultimately just cover for someone else’s bad practices. Every effort should be made to address root causes and do IT right.

Ironic TL; DR at the end: Automation can be a huge boon to the department or company that implements it. When it’s done right, it can make life better for the IT professional, save the company money, and make it more responsive to its clients. Win, win, win.