Blog
Kubernetes January 9, 2020

Death by a Thousand Scripts

In my last five years of exposure to OpenSource 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

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,

Above all, this approach leaves you entangled in a web of customized scripts that results 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:

In the case of an OpenSource 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.

At Loodse, we develop both open source and proprietary products that address this issue and help businesses avoid creating snowflake systems:

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

Haresh Kheskani

Haresh Kheskani

VP of Product Management

Through cookies we deliver improved web content and provide you with a personalised experience. By using this site you agree to our