The good, the bad and the ugly of Scripts in Production

Photo by Hitesh Choudhary on Unsplash

If you can think it — script it

I love scripting. I have been scripting since I started to develop.

I have written scripts in different scripting languages starting from basic, batch, bash, VBScript, JavaScript, phyton, perl, and my personal favorite — PowerShell.

Many “scripting languages”, especially Python and PowerShell until recently were only used for the “gluing work”, but nowadays with cloud technologies more and more scripting languages make it to the “real languages” domain.

I’d like to share my view on what the benefits of using scripting languages and why it is okay to use them even in production environments without hesitation.

Not long ago, when I asked my developer friends: “What do you think about running scripts in a production environment?” 4 out of 5 said that they think it was a bad idea and they couldn’t really explain why. So, I asked more questions. Most of their reasons focused on “it doesn’t feel right” running code that is not compiled, plain text, a code that has not gone through a standard SDLC.

However, if you were to ask IT experts the same question, I believe the answers would be different. My assumption is that 4 out of 5 would say that they do it every day and feel comfortable with it. The fifth would need some time to remember that while he might not have done it, his predecessor likely did. One example that IT experts commonly use are login scripts of users in the corporate domain. I’m sure that would count as a script running in a production environment, don’t you?

Also, DevOps engineers use scripts in their production environments all the time. Serverless development is usually based on non-compiled code.

So why do you avoid using scripts in our production environments? Why doesn’t it “feel right”? What are you afraid of?

The Good

• The agility that you get from running a script, as there is no need to wait for a long build process with all the dependencies.
• You don’t need to compile scripts, most scripting languages rely on existing engines in the OS
  For example: VBScript, JavaScript, batch, bash
  PowerShell can be run by default for any modern Windows version

The Bad

• Since scripts are not compiled and kept “plain text”, anyone with no special skills can see and edit your code. If the script falls into the wrong hands it could lead to a catastrophe when it runs in production
• Troubleshooting is hard
  No simple breakpoint processes
  No stack traces
  Some scripting language don’t have a native IDE

The Ugly

• There are no standard project layouts
• There are no real code standards that are common between scripts developers
  “Wild Wild west” kind of atmosphere
  Potentially longer learning curves when joining a new project
  This causes in most times very messed up and unmaintainable code
• Scripts sometimes are based on whatever API is available, sometimes there is a combination of different things that happen to exist on a specific machine which causes them not being reusable

So why then the world of DevOps and modern development world (developing in the cloud) chose to use scripting languages, running scripts in production every day?

Is it because of the agility? Is it because of the size of files deployed?

Unspoken answers

While other “real program” languages suffer less from the items that are Bad or Ugly for scripts, the agility prevailed. In the age of cloud and “infrastructure as code”, a separation between the “artifact” and the “environment” is becoming more and more blurry as both are needed to deploy to production. At the end it makes more sense to use the same language for both purposes.

Today, there are scripts used in production in various forms and for different use cases. IT experts are scripting for anything they need to run on more than no computer/user, DevOps engineers that are controlling a complex build process of a program for example, Cloud developers developing serverless programs and I’m sure there are plenty more examples just like these. All these use cases are looking for the quick solution that has the little prerequisites and that would be the easiest to deploy.

Although I think that most DevOps developers and Cloud developers don’t refer themselves as writing Script code (not to be taboo by their fellow developers), I still think that they are using scripting techniques and enjoy the scripting benefits. If they are running scripts in production, why can’t you?

Run scripts in production

Years ago, my father (at the time Division manager in R&D), told me that writing scripts is not developing. Code that is not compiled, cannot be considered a real “program” and should not be run in a production environment. I think that today’s trends are proving that you should harness the power of scripting and use them in production.

I agree it’s hard to imagine a full-blown system with complex business logic developed as a script, reframe that as a serverless application that is running mainly python code and suddenly things seem logical. All of this would not have been possible if not for scripts.

For me, I did learn other “real” development languages (Java, C++, C#) but I always continued scripting. Scripting small things, complex scripts and just for fun and pure education scripts. All of them run in production every day.