I’ve long held the belief that for any task there are correct approaches and incorrect ones. When I was small, I remember being so impressed by the huge variety of parts my father had in his tool chest. Once, I watched him repair a television remote control, one that had shaped and tapered plastic buttons. The replacement from RCA/Zenith, I believe at the time, cost upwards of $150. He opened the broken device, determined that the problem was that the tongue on the existing button had broken, and rather than epoxy the old one back together, he carved and buffed an old bakelite knob into the proper shape, attached it in place of the original one, and ultimately, the final product looked and performed as if it were the original. It didn’t even look different than it had. This, to me, was the ultimate accomplishment. Almost as the Hippocratic Oath dictates, above all, do no harm. It was magic.

When all you have is a hammer, everything is a nail, right? But that sure is the wrong approach.

Today, my favorite outside work activity is the building and maintaining guitars. When I began doing this, I didn’t own some of the key tools. For example, an entire series of “Needle Files” and crown files are appropriate for the shaping and repair of frets on the neck. While not a very expensive purchase, all other tools would fail in the task at hand. The correct Allen wrench is necessary for fixing the torsion rod on the neck. And the ideal soldering iron is critical for proper wiring of pickups, potentiometers, and the jack. Of course, when sanding, a variety of grades are also necessary. Not to mention, a selection of paints, brushes, stains, and lacquers.

The same can be said of DevOps. Programming languages are designed for specific purposes, and there have been many advances in the past few years pointing to the tasks that a scripting task may require. Many might use Bash, batch, or PowerShell to do their tasks. Others may choose PHP or Ruby on Rails, while still others choose Python as their scripting tools. Today, it is my belief that no one tool can accomplish all the tasks necessary to perform these tasks. There are nuances to each language, but one thing for certain is that many tasks require the collaborative conversation between these tools. In order to do these tasks, the ideal tools, to accomplish the required steps will likely call functions back and forth from other scripting languages. And while putting together some of these tasks may require bits of code here and there, it is also the best way today, while these tools don’t exist yet in many cases in packaged form, easier to consume, and potentially to be used by staff, writing and maintaining these bits to ensure that each time they’re called upon they’re accurate is key to the job of the DevOps engineer.

As correctly stated in comments on my previous posting, I need to stress that there must be testing prior to utilizing these custom pieces of code to ensure that other changes that may have taken place within the infrastructure are accounted for, each time these scripts are set to task.

I recommend that anyone who is in DevOps get up to speed on these and other languages, get comfortable, and learn for themselves which do the job best so that they become more adept at the challenges they face.

At some point, there will be automation tools, with slick GUI interfaces which may address many or even all of these needs when they arise, but for the moment, it’d be advantageous to learn, utilize and customize scripting tools such as these. When these tools do become available, the question is, will they surmount the automation tools you’ve already created via your DevOps? I cannot predict.