I originally wrote this blog post a couple weeks ago and was planning on publishing it today. I started the post with this line: “Let me start by saying this: Scripts are awesome!”. But today I read Duncans post titled “Automation is scary!“. And I partly agree with Duncan, automation can be scary. But I think not all automation is scary so I’ll start this post with a slightly modified line…”
Let me start by saying this: Scripts are scary! They can do the tedious tasks for you, they can be scheduled so you never forget to delete a snapshot again, they can be used to offload your work to less skilled colleagues, they can save you time and frustration.However, Most scripts used are not written by the user. They are usually left by your predecessor, downloaded from blogs, copied from tutorials and what not. On top of that if somebody tells you he “Hacked some scripts together” you are left with the feeling it’s a quick and dirty solution. So while scripts are awesome there appears to be something wrong with them which make them scary as well. So let’s dig a little deeper into what’s scary about scripts.
Have you ever taken over the responsibilities of another administrator who was really into “automating” his work? Just to discover that he has a million scripts somewhere on a file server which do all his work for him? How did that work out for you? Would you use all of those scripts?
Probably not. I know I wouldn’t. Because I don’t have a clue what each script exactly does, for which version of whatever software it was developed, if it was tested thoroughly, in which order they are supposed to run and so on and so forth. In all likelihood there will be no, or very little documentation. So when you have to deploy a new VM you have no clue if you need to run the “reserve IP” scripts first and then the “Deploy VM” script or the other way around. So the best course of action would be to not use the scripts and first figure out how the process is done manually.
But that’s a shame really. Because there was a lot of time spend on developing the scripts and they could saved you a lot of time as well. Over time you will probably develop new scripts for the same, or new, tasks. Which is just more time wasted.
Now let’s compare this with workflows in vCenter Orchestrator. Instead of a bunch of undocumented scripts you have a collection of workflows. Each one has a meaningful name, comes with a version history, displays what it is going to do and can hold a description or even nice “sticky notes” explaining what is going on. But more importantly, they execute a whole process instead of just one task.
And that’s the major difference between scripts and workflows: Workflows automate processes, scripts automate tasks. Actually, workflows just consist of a number of scripts because that’s what workflows do: executing all tasks in a certain process.
The good news is: if you happen to have a ton of powershell scripts laying around, you can use these in a vCO workflow just fine. One fair warning for the PowerCLI enthusiasts out there though: Once you start learning vCO you’ll probably use less and less powershell…..