Three Reasons Why Scripts are Automation 1.0

Many solutions on the IT automation market are script bound – and why not? Scripts are the way we have been doing automation in IT operations for the past 30 odd years and they have served us well. But if we are just to continue things like we were doing them already, why is there such hype about automation now? Well, simply because the cost of operating IT is too high – despite the scripting we have already done – and because the talent parked in IT operations is missing in the innovation part of IT – which is what IT should all be about.

Naturally many reactions to the need for better automations are to refine things as they are and come up with better ways to write, manage and maintain scripts. Alternatively a disruptive leap in technology can achieve a completely new way of doing automation (the latter is what we are doing with the arago Autopilot for IT operation).

In either case you have to understand the shortcomings of scripts in order to make any improvement and this post is a brief and blunt summary of these shortcomings. Don’t get me wrong. I am not saying all scripting is crap and all the people who have written or are writing scripts are idiots – far from it. As I said scripts have served us well and will play an important role as they are the foundation of today’s IT operations, but we have to understand the limitations of scripts in order to push forward.

In my books there are three limitations to scripts and I will outline them here:

  1. Limited applicability
    Limited Applicability
    A script – like any other imperative computer program – has a clear precondition under which it will produce the desired result. Basically this means a script is like an assembly line. It will produce the correct result – reliably and mostly scalable – if applied to the context the script was written for. If the context changes only slightly the results are wrong or the script cannot be executed. This means for every slight change in context the script has to be reviewed as a whole and can either be cloned or changed so that it can handle the slightly changed context as well. This normally means adding “if” or “case” statements to a script and making it more complex. If you do this for long enough your script will evolve into a tool and if you do not stop there you might even end up with an organically grown product. The problem with such tools is that they become absolutely impossible to maintain, because scripts are nor managed like programming projects (which they were never intended to be) but can easily evolve to become huge programs.
    This limited applicability either creates a great many very similar scripts or some very complex scripts and if you look into any standard IT operations environment you will find such things – and no one really wants to touch them unless absolutely necessary, because no one understands them completely or the interdependencies between the many scripts in the environment.

  2. Limited reusability
    Limited Reuse
    IT operations is an ad-hoc business. Even if we do not really like to admit it, the job of IT ops is to handle events as they occur. Meaning that there is no long planning phase to get the reuse between all components involved in operations up to an optimal level. The job of IT ops is to get things done now and this is also how most scripts are generated. Someone does a job for the tenth time and needs it done faster or is annoyed that this thing gets in his way of completing other important assignments and in order to prevent that from happening again he writes a script. This is good and it produces instant results (what we are looking for) but it also means that things are scripted over and over again. There is simply no time to properly manage reuse of things that are already available or even to make the knowledge what has already been done by others available to everyone. This means that not only a great deal of time is spent writing parts of scripts that are already there (which is bad in hindsight but ok in terms of results achieved) but it also means that if change occurs in an environment there are potentially MANY MANY places where this change can affect current operations procedures (i.e. scripts).

  3. Limited flexibility
    Limited Flexibility
    Assuming we have been writing scripts for more than 30 years I believe it is safe to assume that all the low hanging fruit have been picked. In scripting terms this means that all the easy scripts are already there. Easy normally means something you can create all by yourself. Yes, I know you can create wonderfully complex scripts and programs all alone, but as long as you are the one who has to deal with them they are easy, because you know how to deal with them. Scripts become complicated, when you need more than one expertise – i.e. person – to write and thus to maintain them. Because at first it is hard to bring these two or more people together in order to write the new script and then it becomes even harder to bring them together again to change it. This means that because of this strong dependency on several skills in moderns scripts they are only changed as part of a dedicated change or refactoring effort or in case of utter emergency. Since IT operations has enough work as it is the dedicated change effort is something everyone dreams about and no one ever gets around to doing. And this in term means that changing the context – i.e. environment – in which these scripts are running cannot be done without creating a storm of additional tasks in changing all the things that have grown over the years and help maintain an environment.

To me the part 3 is the worst, because this is the simple reason why everyone understands that the “never change a running system” rule is not only followed but the status quo of a system is defended like it was the last bastion of humanity or admin appreciation. And if you cannot change your environment you cannot accommodate business requirements – or accommodating is always a big fight for everyone involved – and you can absolutely not entertain innovation as a constant companion in IT – which according to all the IT literature I have read is what IT should be all about and which is what makes IT people love IT.

All three points together make maintaining an IT operational environment an expensive and time consuming task and changing an IT operations environment an almost impossible mission.

Many people have seen these limitations or constraints of scripts and there are many products out there to help us overcome one or more of the restrictions mentioned above. Many of these approaches have fancy names like run-book automation or data-centre automation, but they are simply better ways of managing scripts, managing reusability in scripts or managing tasks to be scripted. I believe that this is not enough, because IT changes too fast to make a script that needs lifecycle management and everything attached with it an effective way to handle things. The result of elaborate operational lifecycle management normally is a very standardized environment that is slow to react to new requirements. Such an environment is great for commodity products and services like desktop provisioning or server provisioning, but it is not good for application maintenance, user feedback management and the like.

This is why a different approach is a good idea. Our approach is called autopilot and all the autopilot does is to have a big pool of knowledge (like you do) and write a script on the fly every time a task comes up (like you do when you handle something manually). The effects of this are simple. You do the interesting new stuff and the autopilot does the boring work, even in a changing and ever more complex environment – without the need to standardize everything.

Leave a Reply