posted by Mike Mazzolini
Stop Writing Scripts
Please, I beg you, “Stop!” Yes, stop writing scripts and instead build workflows.
Programmers, Sys-Admins, System Support, I’m talking to you.
There was a time when writing scripts to help support IT infrastructures and changing business processes was the best option.
That time is gone. Todays computing systems are rapidly growing in complexity and the need for easier integration and better automation to manage these systems is becoming paramount.
“So where do we go from scripts”?, you ask. “That is the right question”, making reference back to the movie “iRobot” discussed in my previous blog entry “Three Laws of IT Automation”.
In the following text, I will try and answer that question explaining why building workflows instead of scripts may be the answer.
What is a Workflow?
In the IT world, the term “workflow” is very overused. So let’s begin by providing some context on the subject.
A workflow is generally described as, “A sequence of steps by which a piece of work passes from initiated to completion”.
In IT process automation, a workflow engine or management system is required in order to carry out the workflow. In this text, we will refer to workflow and workflow engine as one in the same.
Script Hell
Why do scripts fail?
If you are an IT professional, you most certainly have written a script or two in your time. Scripts are written to automate tasks with the general objective to be more productive and reduce errors. In the early stages of an organization or while its environment is small, writing a few scripts seems to add benefit and meet its objectives. However, over time the environment changes, grows and becomes more complex. This results in more tasks, which in turn requires the need to write more scripts. Soon, the ability to manage these scripts themselves becomes overwhelming - welcome to script hell.
Let’s examine more precisely the challenges IT staffs face as they enter the script hell zone.
Little Security
In general, scripts are run as the user executing the script. However, there are times when it is necessary to run the script with elevated privileges which is not permissible without the use of third party program. Worse yet, logins and passwords are embedded in clear text in a script which compromises security.
Lack of Reuse
Many scripting languages, e.g., bash, batch, are not very conducive to reusability. IT personnel find themselves recreating the same scripts over and over for different projects. This leads to both copy/paste errors and code drift.
Not Cross-platform
In cross-platform environment, e.g., those that contain Unix|Linux and Windows, script writers are forced to maintain 2 or more versions of the same script that is implemented for a particular platform. This leads to more maintenance, inconsistencies and errors.
Hard to Maintain
Scripting languages can be very hard to read and understand making ongoing support and maintenance of support scripts problematic as the organization changes. For example, the original author of a script may change roles or worse leave the organization. The responsibility shifts to another individual that needs to decipher how this script functions. This can take significant effort and lead to errors.
Workflows, A Better Alternative
Why is a Workflow better?
Being in the process automation business and a proponent of workflows, often, I am presented the question, “Why is a workflow better than a script”? I love this question because it gets to the heart of serious IT automation.
Workflows allow users to program or generate automation processes at a higher abstraction level to more easily deal with the growing complexity of technology. Unlike a script (At least one without a significant amount of development) workflows can perform any number of tasks in an asynchronous fashion. Workflows can separate behavior and data allowing for components to be easily reused. In simple terms, a workflow overcomes all the short-comings of scripts as described above.
Security with Flexibility
Workflows leverage the environments underlying security allowing the ability to perform all necessary steps as appropriate for the given roles. If roles don’t satisfy the necessary security it is possible for the workflow to run with elevated privileges if it gets approval from another system or user with appropriate roles.
Reusability
Workflows can be built and reused by other workflows. For example, an organization may want to define a consistent escalation procedure for process failures. A workflow can be built that implements this escalation procedure and called by any number of other workflows as needed.
Platform Abstraction
Workflows will abstract the platform layer. This allows IT personnel to build a single process that operates cross-platform and reducing copy/paste errors and eliminating code drift.
Self Documenting
Workflows can be much easier to understand than a script. They can be graphically modeled and provide an almost self-documenting ability. This makes workflows much easier to maintain long-term as the environment changes.
Conclusion
Todays technology is moving, changing and growing in complexity at an incredible rate. The IT community needs to keep pace or be crushed by the same systems it hoped would provide greater productivity. So, I’ll end where I started and say again, “Stop!”. Stop writing scripts and instead build workflows.
