IT Ops Must go Beyond Scripting to Automation

Pop quiz – which is heavier? A pound of feathers or a pound of rocks?

Trick question, of course. A pound is a pound. There’s just a lot more feathers in a pound than there are rocks.

Okay, on a more related topic, which is faster? A script executed via a manual command or a script invoked via an API call?

At this point, you’ve likely deduced that the answer is like the first and answered there is no difference. At least not a discernable difference.

A script is a script, and its execution time doesn’t rely on its method of invocation. Whether kicked off by a manual command or invoked via an API, the script is going to run as fast as it’s going to run. Period.

This is important because improving the velocity of operations with automation isn’t about really about scripting, it’s about a process. It’s about the hand off. You’re never going to optimize deployments if you focus just on the scripting of individual steps in the process. You must go higher, up to the process itself, before you’re going to see real improvement.

The goal of automation in every industry is almost always optimization. We saw that in our 2018 State of Application Delivery survey, where 72% of respondents with a digital transformation initiative pegged “IT optimization” as the number one expected benefit. The goal was optimization.

To optimize means finding and eliminating bottlenecks. In the world of IT that’s almost always the hand offs between steps in an operational process. The actual work – the scripts – is the value. The time between those scripts executing is almost always the source of delay and frustration for those waiting on the output. The majority (52%) of NetOps still manage infrastructure in this way. 

It’s not enough for each operational domain to script its part in the process. Scripting a firewall change, the provisioning and configuration of application services, and standing up the app infrastructure are all individually good things to do. But that’s just the beginning. Together these individual automated steps comprise a single, operational process. Automating that is what we call orchestration. And it’s in orchestration that we find the delays and faulty hand-offs that introduce the inefficiencies dragging ITOps down. 

Here’s where culture and organizational structure matter. If you’re the first step in the deployment process – say standing up the app infrastructure – then you’re the one that must hand off the process to the next step in line. That’s likely the application services (load balancing, etc.) provisioning step.

Who do you hand that to? Does it go to a queue? Do you generate a ticket? How does that work?

It should be a seamless transition, either governed by an overarching playbook (recipe, cookbook, manifest, etc.) or by some external system that oversees the execution of the process. The introduction of manual interaction in the execution of the process means you’re not really taking advantage of automation, you’re just scripting.

And while scripts may be an integral component of your automation strategy, they aren’t themselves automation because they fail to integrate with the governing process that drives them.

If you’re going to optimize IT using automation, then you need to automate processes. Because that’s how you eliminate wait times and ferret out the ossified operational processes (including three-layers of sign-offs) that will actual improve performance and increase velocity in a meaningful way.   

Automation – not just scripting – is a sign of a maturing NetOps practice that gets you a step closer to the goal of an agile network.