Home > Blogs > VMware CloudOps


Automation – The Scripting, Orchestration, and Technology Love Triangle

By Andy Troup

In speaking with some of my customers, the message comes resoundingly across “WE WANT TO AUTOMATE.” So this is the sweet spot for cloud solutions as they have in-built automation to provide the defined benefits of cloud computing such as On-demand self service, Resource pooling and Rapid elasticity (as defined by NIST here).

However, upon scratching the surface and digging a little deeper, the other thing I’ve found is that when I’m told “yes we’ve got automation,” it typically means that a lot of effort has gone into developing a whole heap of scripts that have been written to solve a very specific problem. This, I would argue, is not the best way for automation to be achieved.

I was in conversation with a customer a few weeks ago where they wanted to automate a particular part of their provisioning process, and my recommendation to them was “DON’T DO IT.” Why did I say this? Well, the process was broken, inefficient, relied on spreadsheets & scripts and meant there was constant rework to have a satisfactorily provisioned system. Their provisioning process took weeks and weeks. There was no point in automating this broken process – what needed to happen was that the process had to be fixed or changed first. I won’t go into anymore detail about this particular problem, but my point is that sometimes you have to take a step back and see if there are other ways of solving a particular problem.

In summary – there’s no point in automating a broken process.

So, why do we want to automate our IT systems and the provisioning of them anyway? Primarily because we want two things:

  1. To take the boring repeatable activities that many IT administrators undertake and get a system to do it instead. This frees up time for the administrator to do the more interesting and difficult things.
  2. Remove the potential for errors. Anything that is done as a manual activity involving people is liable to be inconsistent and error-prone (I say liable, but really we all know that they will be inconsistent and error-prone). Cloud solutions are all based on the premise that everything is standardized, and thus we need to remove any activity that introduces unreliability.

OK, so we’ve now established that automation is a good thing. All we need to do now is work out HOW we’re going to automate, and this may introduce some difficult decisions.

So what are the automation options? Well, in my mind automation comes in three different flavours which should be used together to solve the automation challenge. Here they are with some definitions I found:

  1. Script - programs written for a special runtime environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator. (http://en.wikipedia.org/wiki/Script_(computing))
  2. Orchestration - describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services. (http://en.wikipedia.org/wiki/Orchestration_(computing))
  3. Policy - Policy-based management is an administrative approach that is used to simplify the management of a given endeavor by establishing policies to deal with situations that are likely to occur. (http://whatis.techtarget.com/definition/policy-based-management)

In terms of their use, the image below shows how I believe they should be used and in what quantities. As you can see, we should be aiming for as much policy implementation as possible with as little script as we can achieve.

If you have a process you’d like to automate, to find the solution, you should work up the pyramid from the bottom.

So the first question you should ask yourself is “can I create a policy or several policies to solve the problem?” This will have a dependency on the technology available to utilize the policy, but should be the first port of call. It may even be worth considering investing in the technology to make the policy implementation possible. The overhead of creating and maintaining policies are small and they will provide a robust solution to your problem with reliability and consistency.

If it isn’t possible to create a policy to solve the challenge, next consider orchestrating a solution. This will provide a reusable, standardized capability that has an element of management/maintenance overhead and will be reliable.

Finally, if neither policy nor orchestration will work for you, then utilize scripting as a last resort. Why a last resort? Scripting is a tactical, bespoke solution for a specific requirement and will require managing and maintenance during its entire life, which in turn will incur costs and will be less reliable.

So in summary, when you are considering automating a process:

  • Step back from the automation challenge and consider the options. They may not be what you expected.
  • Work up the “Love Triangle” from the bottom.
  • If you can’t implement a policy, consider orchestration and use scripting as a last resort.

For more great insight on automation, see our previous posts highlighting automation economics and IT automation roles.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

8 thoughts on “Automation – The Scripting, Orchestration, and Technology Love Triangle

  1. Pingback: VMware Cloud Ops Blog: Automated Deployment and Testing Big ‘Hairball’ Application Stacks | System Knowledge Base

  2. Jason Hofferle

    Very insightful article that is applicable to many situations beyond the provisioning of virtual machines. It’s very common to see new technology thrown at problems with very little time spent reflecting on the process itself and how well it’s working.

    1. Andy Troup

      I couldn’t agree more. How many times have we seen shelfware when the tech was put in, but it wasn’t integrated into the organisations process, and the people who would be using it weren’t considered?

      This is the problem that cloud Ops is specifically trying to solve.

  3. MattHitchcock

    This really all depends on how you script. Traditional scripting (one script running multiple tasks in succession with no reusable code), yes, I agree with you, but modular scripting is very, very workable, or perhaps that would fit into your orchestration section? Lets be honest, the leading Orchestration products are doing almost exactly this (running modular, reuseable code) under the hood anyway.

    The value of scripting still cannot be underestimated. One person maintaining scripts all year long is still better than 10 button clickers.

    1. Andy Troup

      Agreed – reusable, modular code is what we’re looking for – blueprints if you like, but I guess my point is that coding (of whatever form) should be the second option, not the first. Look for the policy driven solution first, and work your way up the love triangle until you find the best way to solve the problem.

  4. Terry Curtis

    Good article Andy. Most if not all customers I speak to also want to simplify and standardize there IT operations. Although I still see scripts very heavily used, in my opinion they are simply an historic way of automating a task.

    Scripting requires maintenance to keep them current within an ever changing IT infrastructure that is ultimately providing a service. Service needs tend to change over time with newer services being required and/or changes to existing ones. Scripts may not ever fully disappear but I agree less is better for customers that want to automate and simplify their IT operations.

    1. Andy Troup

      Hi Terry,

      Its been a while!!

      My point is that we’re trying to get away from the traditional way of operating. Whether you have someone in operations manually doing things, or spending time fixing & maintaing scripts, it is not the best use of their time. So step back and ask “why do we do it this way” has to be the way forward so people can become more effective.

      1. Terry Curtis

        Hi Andy yep I agree. Automation is the defining word. For a truly standardized and automated IT model then more policy and orchestration is required with less manual intervention, regardless of the provisioning request.

Comments are closed.