Skip to main content

Use the Right Tool for the Job

Image copyright (c) by James Aiken
My wife and I have a fun dynamic: she approaches situations with surgical precision, while I tend to be more of an imprecise paintbrush like you would imagine was used in the painting you see here. One day, she chastised me one day for cutting something with a butter knife and insisted that I should be using a paring knife instead.  I argued that it wasn't needed.

Who was right?

As you can imagine, I was intentionally vague with the description of the situation above so that I could illustrate that an understanding of the context is required to answer it properly.  In this particular situation, I already had the knife out from making my daughter a sandwich for her lunchbox and had switched to cutting strawberries.  So, technically, she was correct, but I was also able to properly execute my task with the tool at hand, literally.

This loosey-goosey approach to executing a process works in some situations, but in others it should be avoided at all costs.  Would a MacGyver approach work with DevOps?  Could you slap together a bunch of unrelated tools in such a way that the proverbial "bubblegum + aluminum foil" result allows you to have an enterprise class CICD solution?  The answer is "probably not."  Yet I have found numerous organizations that attempt to shoehorn single purpose solutions like Jenkins or Chef into the role of CICD orchestrator, only to wonder what went wrong when the level of effort ends up being immense and/or yields something that either doesn't meet their expectations or isn't able to grow with them as an organization.

As with the example about cutting strawberries, context is needed here.  Many commonly used DevOps solutions are single-minded in their purpose:  Jenkins was built to be a continuous integration tool; Chef was built to be a provisioning / configuration management tool; etc.  And just like you wouldn't use bubblegum and aluminum foil to build a jet engine, you shouldn't use solutions to do things they weren't intended to do.  This includes situations where the company that produces such a solution releases a subsequent bolt-on in hopes of expanding the scope of use to include use cases that should not be considered in the first place.  (I'm looking at you, Chef.)

With continuous delivery, specifically, you need to realize that any orchestration solution needs to be able to address the following six verbs:

Who should have access to various applications and processes that are part of an organizational portfolio?  Roll-based access control should allow you to limit who has access to what so that developers on one team can't modify applications being built by other teams, or deploy an application into operational environments to which they don't normally have access.

What artifacts should be included as part of the application deployment process?  Are all artifact types supported by the solution?

Where is the application to be deployed?  Does the solution allow you to deploy across multiple environments while automatically adapting the workflow to account for environment-specific configuration differences?

When do deployments occur?  Can it be on-demand?  Scheduled via a release calendar?  Queued up so that a different function can decide when the queue should be processed?

Why are you using an enterprise class orchestration solution?  Are you still doing enterprise releases twice a year or are you looking to increase the frequency of deployments to be once a week or more frequently than that?  And...

How does an application get deployed?  How is the process defined?  How are integrations with surrounding parts of the ecosystem (e.g. ITSM solutions, etc.) accomplished?

Applying this litmus test to the commonly used solutions like Jenkins, Bamboo, etc. will show you that these solutions often excel in one or possibly two of these areas, but rarely will you find something that addresses all six in a way that allows your organization to benefit without adding risk to the operational side of the business.

The onus is on you to understand the raison d'être of your toolset so that you can also understand why changes may be needed.  If you are looking to expand your capabilities so that you can deliver business functionality to your end users in an expedited fashion while also putting structure around the process so that there is no risk added as a result of the increase in velocity, then you need to stick to evaluating orchestration solutions that were built for this purpose from the beginning.  This will give you the confidence to move forward with the implementation of your CICD strategy.

Popular posts from this blog

"Ni jiang yi yang de hua ma?"

Last week, I wrote about the necessity of having a clear message . Because this topic is so important I decided to follow-up with another entry on this general subject. This week we will approach it from another angle. (For the curious, the title says " Do you speak the same language? " in pinyin, which is a transliterated Mandarin Chinese.) Recently, a good friend of mine (who is Chinese, ironically) and I were playing pool. He had to bank the 8-ball in the pocket to win the game, and since it was an informal game and bank shots are my area of expertise, he asked me for advice. I told him, "you just need to strike the cue ball with medium speed so that it hits the 8-ball right in the middle." He didn't believe me so we marked the positions of the balls, and then he took his shot only to watch the 8-ball sail past the pocket. "A-ha!" he exclaimed. "I told you it wasn't that easy." But when we reset the positions and I made an attemp
Read more

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that
Read more

Is No/Low-Code the Key to IT Nirvana?

 Unless you've had your head in the sand for the past year or so, you've seen the phrases low-code  and no-code  bandied about quite frequently everywhere you look.  You've probably wondered if this is something new that's here to stay or just a "flash in the pan."  Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011.  Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998. For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to Isn't this the source code to Roblox? rapidly build full applications with little or no coding requ
Read more