DevOps Tools: A Framework for Tool Selection

I see a barrage of posts here on LinkedIn outlining the vast and never-ending array of DevOps tools that are available.? Depending on the post they are labeled one way or another, sometimes correctly and sometimes not.? My message here today is this: it doesn’t matter.

Tools come and go; they evolve in response to market trends and expand or contract their feature sets based on several market drivers.? Most of the tools you use today can be substituted with a competitor’s equivalent and the outcome would be the same.? Many times, the team or individual who is responsible for deciding which tools are to be utilized is familiar with that vendor and just sticks with what they know.? Or even worse have landed firmly in the “fanboy” genre and just stick with their favorite vendor even if it is not the best solution for the problem that needs to be solved.?

This brings me to the point; tools are in fact solutions to problems.? Truly successful deployments of a specific tool or set of tools solve a well-understood problem. ?A DevOps team can have a deep understanding of every tool on the market, maybe even real-world experience with a wide variety of said tools.? Unless the problem is well understood, along with the requirements and scope for a solution, selecting a tool is nearly pointless.

Most of my career has been running DevOps organizations which includes managing the entire tool stack.? I have a rigid framework I use which has been successful in the years for picking a selection of vendors which together comprise an effective set of solutions for the Engineering organization's problems.?

?

Understand the Problem

I cannot emphasize how important this step is, and it serves as the foundation for the entire tool selection process. ?Problems usually stem from a variety of sources but when they land in the seat of a DevOps team they should be handled with care and taken seriously. ?I have made the mistake of jumping straight to a solution and it was not successful, and it alienated some along the way; there were apologies to be made and I would rather not repeat that mistake.?

If the problem is not well understood, you will not be able to successfully claim that any tool or solution solves the problem.? When you attempt to get approval for the cost of the solution, both in monetary and the team's time, how can you claim with confidence a solution will solve said problem without having it well defined?? When the project is complete and the tool has been implemented, how can you claim success??

?

Decide Stakeholders

Which teams or individuals are stakeholders who are affected by this problem?? Who among them wants to be a part of the solution?? Who among them wants to contribute to the definition of the problem? ?Who among them wants to contribute to defining the requirements of the solution? Who wants to contribute vs merely being informed?? Most importantly, who is the chief decider?

This is a critical step because often the users of the solutions who have a vested interest in its success want to contribute to the selection process.

?

Requirements Definition

This is where stakeholders can decide what requirements are necessary for a tool.? For example, if you are choosing an API Gateway, you might select routing, load balancing, rate limiting and caching but leave out authentication and protocol translation.? For a web server, you might select requirements that include WebSocket and HTTP/2 support but leave out caching.? These requirements will be based on the business use cases (don't forget TCO!) and will likely be unique from company to company, or even team to team within your Engineering Organization.

?

This set of requirements will serve as your selection criteria when deciding on your solution.? They should be ranked in priority according to your business needs.

?

Define Scope

This is a similar step to the requirements definitions.? Will this only be for your API-based products?? Your customer-facing web products?? Will this serve only North American traffic, or can the same solution be used globally?? Again, this will be based on the business use case and will vary greatly.

?

Establish Candidates and Compare

We finally get to the tools!? We can assemble a list of tools that fit our requirements and conduct a head-to-head comparison. ??This should be done without bias for the tool and should be subject to a deep and thorough assessment.? While this can be a lengthy process there are many benefits beyond saying a tool can or cannot satisfy a requirement.? The team conducting the assessment will gain a deeper insight into the tool's functionality and abilities.? Certain tools will be ruled out as they fail to prove their ability to satisfy key requirements.?

This step is crucial and typically starts to point the team to the tool candidates that solve the problem the best.

?

Make a Decision

After a thorough assessment is complete, you have your results which can be presented to the stakeholders and chief decider.?

When you have an unbiased set of results typically there is an obvious solution that checks off all the highest priority requirements.? A decision can be made with confidence and reflects a responsible process.

In the event the tool that was selected turns out to not solve the problem well, the decision that was made is highly defensible and you can return to your tool comparison to revisit the choice.

?

In conclusion

In the dynamic world of DevOps, tools are just a means to an end, a solution to a problem.? If the problem along with the requirements and scope for a solution are well understood a responsible and highly defensible decision can be made.

?This is how well-run DevOps Organizations make critical tool selection decisions.? I welcome all to share their thoughts on what was said here today in the comments

?