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

So What is this IPaaS Stuff, Anyway?

 In my last post , I discussed how no-code/low-code platforms fulfill rapid development of business applications - addressing the needs of the Citizen Developer (a Gartner term  first used around 2009).  I also commented on how this specific objective limits their ability to provide true integration capabilities, which require the flexibility to adapt to the myriad variations of infrastructure.  This is a concern because companies often have acquired legacy systems via M&A activity while simultaneously investing in new technology solutions, resulting in a mishmash of systems with multiple ways of accessing them. In this post, I'd like to examine how the needs of the latter group are met by describing some key capabilities that are "must-haves" for any company looking to execute on a digital transformation strategy.  In order to do this, let's define who the target user base is for such a technology platform. Disclaimer:   I work for MuleSoft (a division...
Read more

Time to Level Up!

With the recent news out of Salesforce and Oracle, it’s easy to understand why folks affected by layoffs might feel discouraged. Not only are they leaving companies they may have called home for years, but they’re also facing the daunting prospect of job hunting while headlines scream about “AI taking over human jobs.” Not long ago, another company I follow - let’s call it Acme  - went through a similar round of layoffs. Two employees in particular (we’ll call them Jim and John) showed how mindset can make all the difference. Jim had been at Acme for over 20 years. He was reliable, steady, and well-liked, but not exactly the standout type. When he was laid off, he decided to take some time off before even thinking about his next move. After all, he had a severance package. Didn’t he deserve a break after two decades of hard work? John’s story was different. Though he hadn’t been at Acme as long, he’d built a strong reputation and had both technical and leadership skills. Instead of...
Read more

COSMIC Insights

Consider the following scenario:  you're a mid-level manager and find out that a layoff is coming.  You're about too lose one of your best direct reports, but you have no ability to influence the decision to lay them off. Oy! My head hurts! What do you do? Oftentimes, I find that people - when presented with situations where they feel compelled to act but have no ability to change the outcome - enter a state of mental lethargy.  They don't know exactly what it is they should do but, "gosh darnit!", something has  to be done.  When they realize how helpless they actually are, they start lamenting about the situation, how they are backed into a corner, etc. In a very real sense, they go through the five stages of grief . I'd like to offer the following alternative way of approaching these and other situations:  I call it the COSMIC method, not only because it sounds cool but also because I like science fiction (" Lisan al Gaib! "). COSMIC is an acronym...
Read more