DevOps Tool Selection: How We Choose the Right Tools for Us


There are many moving parts when developing software but luckily we can outsource a lot of those to 3rd party tools generally, such as Continuous Integration and security tools. But how do you pick the right one of many different options to use?
First we start off by finding tools that support or integrate well with any other tools we currently use and the technology stack behind our new product. For instance you don’t want to pick a tool that doesn’t support your language or source code management tool. After we have selected our initial bunch of options we have to consider a couple factors:
  • Price
  • Value-adds (for customer or us internally)
  • Ease of use
  • Trade-offs 
In general we like to focus on both east of use and the value-adds provided from utilizing a service. Nothing is worse than a cheap tool without proper documentation or support which forces your engineers to spend more time fighting the tool than using it. The price and trade-offs between tools is something we factor in after determining which tools are the easiest to use and offer the largest gains for both us and our customers. For instance if we have a service that integrates well with our stack and provides our customers with a better user experience while also allowing us to easily develop we are okay with paying more for that product even if there is another option that is cheaper but not as easy to use or with lower value-adds. So keep in mind when selecting tooling from a short list of providers that value-adds and ease of use should be highly valued. 

Rent, Make, or Buy

Determining  which product to use is hard enough but what about the option of developing your own? This question is generally difficult to answer so you need to focus on the biggest value-adds you can get either for yourself or your customers depending on who the product is for. The Rent, Make or Buy decision can be made easier by examining your timeline and budget for a project. You probably don’t want to be creating tools from the ground up for a short term or low budget project, it will end up consuming the entirety of your time and you will provide less than sufficient products to your customers. For longer projects with larger budgets and teams is when making your own tool becomes a bit more feasible. But this should only be done if you have determined that your tool can provide ease of use and value-adds for yourself in the future or even as a product offered to other developers on the market. It may be useful to do some market research on the particular tool you want to develop, it could be a great opportunity. The options of renting and buying are likely the two you will come down to for most projects. Renting is best when the project is short term or a proof of concept(PoC). You don’t want to be spending big bucks on licenses for large tools when you don’t know if your customer will choose you for a project. This is how we determine when to rent or when to buy. If we rent a product for a PoC then if that PoC is converted to a fully funded project it makes it even easier to continue using the product so it is then purchased. For larger, more established projects we are much more likely to purchase a tool if the trial period finds that  it fits our needs well. 

Focus on the End Goal

Our goal is always to provide a superior product to our customers. As an example one of our customers provides fleet management services to their customers for the purpose of tracking and managing trucks. One of the value-adds for their customers that we provide is license plate recognition(LPR). LRP is an incredibly complex feature involving training artificial intelligence(AI) models and providing access to them via a fast and convenient API. Due to the duration and budget of this project we determined that it was nearly impossible to support building and training our own AI model. This means that our options were limited to buying or renting a service to utilize to provide this feature to our customers. We did a bit of market research and ended up finding two potential tools to use. After doing some research on each one it came down to ease of use vs. price. We selected the tool that was easier to use but slightly more expensive as that way we could get a PoC together and in front of a customer quicker.

Fleet Management Framework

Rapidly build better fleet & asset apps, with less code.

Blog Author:


Sign up for our Newsletter and stay up to date on the latest at ESG USA.  New blog posts, newsletters, case studies, and more.