{{announcement.body}}
{{announcement.title}}

Death by a Thousand Scripts

DZone 's Guide to

Death by a Thousand Scripts

In this article, learn about scripts and how they are meant for PoC and prototyping phases, not for productization.

· Open Source Zone ·
Free Resource

Death by a Thousand Scripts

In my last five years of exposure to open source software, starting with OpenStack, I have noticed an increasing trend of relying on scripts to fill the gaps left by the software system. The gaps can be varied in their scope and size, such as

  • Installation
  • Lifecycle management — upgrades, downgrades, etc.
  • Supporting different environments
  • Troubleshooting
  • Feature extensions

While this approach may help with the initial PoC steps to get things off the ground, it can cause a lot of problems later on during the productization cycle. Ultimately, this leads to a software system that is heavily propped up by a multitude of scripts.

Once the system goes into production, there are many scenarios where the scripts make the situation more challenging. For example,

  • In case of a failure, you are forced to debug your scripts before reporting the problem to the open source community
  • In case of supporting a new environment, you have to rewrite all the scripts or create another set of scripts for the new environment
  • In case of feature extensions, all the scripts have to be updated for every open source release
  • In case of troubleshooting hooks, all the scripts have to be updated for every open source release
  • During the upgrade cycle of the open source code base, the lifecycle management scripts are likely to require an upgrade
  • It is hard to build an end-to-end test system to validate your scripts
  • As time progresses, the code base of the scripts gets more and more complicated and hard to maintain
You may also be interested in:  10 Best Open Source Test Automation Frameworks for Every Purpose

Above all, this approach leaves you entangled in a web of customized scripts that result in a “snowflake” software system. As a result, you are largely left to solve your own problems without much support from the community or the relevant vendors.

However, this unmaintainable pile of scripts does not have to be the inevitable status quo. By carefully choosing projects (open source) or products (proprietary) it is possible to reduce the number of scripts to a manageable amount or eliminate them completely. Based on my experience, they should be able to meet the following requirements:

  • Easy to install
  • Support Lifecycle management
  • Support a variety of environments as well as the addition of new ones
  • Easy to troubleshoot
  • Support feature extensions/additions
  • Production-ready, which includes quality, scalability, etc

In the case of an open source project, the architecture should be flexible and modular enough so that you can fill the gaps by contributing to the project. While in the case of a proprietary product, the architecture should allow the vendor to be able to fill the gaps in short order.

In general, scripts are meant for PoC and prototyping phases, not for productization. At the time of production, you should be able to raise both your arms up and say “Look Ma, no scripts.”

Further Reading

Functions in Shell Script

Understanding Gatling Scripts: A Use Case

Topics:
kubernetes ,open source ,scripts ,openstack ,poc

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}