This content is part of the Conference Coverage: IBM roadmap of cloud, AI-enabled IT drives Think conference

Shrink the DevOps tool stack and grow its power

Given an embarrassment of riches, DevOps teams must discover what they need from tools and how to pick and propagate a cohesive tool stack across multiple teams.

DevOps organizational change imposes an IT tooling rethink. Empowered, product-focused, multidisciplinary teams wrestle with an overlapping array of options, and tool sprawl ensues.

"DevOps can be an infinite loop of tools," said Nimesh Misra, director of global development operations at Varian Medical Systems, a medical device maker in Palo Alto, Calif. We don't want to become ruled by the set of tools we carry around that is not efficient, he said, presenting at Delivery of Things World 2017 in San Diego. Instead, organizations must pare down a DevOps tool stack that works for the architecture and the team. It's easier said than done.

Developers seek tools that integrate together, primarily to cover continuous integration and delivery, including test. Operations professionals have a maniacal drive to convert manual work to automated processes, with tools for cloud infrastructure management, monitoring, security and reliability assurance. Skill levels and DevOps maturity will vary from one cross-functional team to another, and everyone has tool biases.

DevOps advocates use techniques from gentle persuasion to strict directives to combat tool sprawl.

DevOps for product and infrastructure
Figure 1. DevOps combines product design and infrastructure automation through various tools.

Not every tool goes in the box

To winnow the tool pile down to a valuable few, establish what goal you're trying to achieve and the process to get there.

Rajashekar Srinivas, cloud evangelist at Barclaycard, the multinational credit card and payment services company, outlined how much goes into even a basic DevOps tool stack at Delivery of Things World:

  • a development pipeline with code repository, build and integration tools and a build and artifact repository;
  • test and preproduction covering functional and integrated quality assurance and user acceptance testing;
  • production where incident management, logs and other monitoring and reporting tools, backup and security come into play; then
  • feedback from production's tool stack to the developers for code improvement and optimization.

Multiple tools are available for every step. Vendors aren't your only concern, because developers can go overboard writing their own tools, said Ron Forrester and Scott Boecker of Nike, speaking at DevOps Enterprise Summit 2017 in San Francisco.

Establish what the teams need to do, and use this as a filter to find the best products. Ask questions, Srinivas suggested, such as whether a multipurpose tool can cover everything for a given part of the stack or whether a task requires the specialized function of one particular tool. And Nike's team advised against too much in-house innovation, suggesting that developers should make features, not reinvent the test automation or monitoring system wheel.

Sure, there are differences between a $5 hammer and a $50 hammer, but they can both do the job. Not everyone has to use the same hammer.
Michael BibeauJaguar Land Rover Automotive

Tool function is more meaningful than tool brand, said Michael Bibeau, a Portland, Ore.-based software development manager at Jaguar Land Rover Automotive, which is underway on a DevOps transformation for automotive software, such as infotainment systems. "Sure, there are differences between a $5 hammer and a $50 hammer, but they can both do the job," he said. "Not everyone has to use the same hammer."

A goal-based selection technique for the DevOps tool stack is especially helpful to undo existing sprawl, where teams use and like a mix of pipelines, automation platforms and other software.

"The last thing that you want in a conversation with a developer is to say, 'You've got to change your tool, and you have to use a new tool,'" said Nanda Kumar, fellow at Verizon Global Technology Services, at DevOps Enterprise Summit. Instead, define what you want to achieve, focus on an outcome and let the team determine the best way to reach it, he said. They'll gravitate toward whatever makes the task easy.

Choose any color, so long as it's black

Many businesses aim for a single uniform DevOps tool chain used by everyone, packaged and offered as a product to the cross-functional groups.

Paradoxically, a standardized DevOps tool stack can arise from intense experimentation. Different groups each try tools and communicate what they like -- and don't like -- about how they work. Then, the organization as a whole narrows down the best products based on real experience.

Standardization is an important part of the maturation process, but it doesn't happen overnight. "If you look at an assembly line that builds our cars, those robots putting in screws and so on probably weren't all the same [model] at first, but now, they are," Bibeau said.

Another analogy -- surprisingly not from the automotive IT pro -- is that disparate tool stacks are like a dirt road. You'll reach the destination, but it won't be easy, said Carlos Rojas, director of operations and technology at Fannie Mae.

Fannie Mae DevOps tool stack
Figure 2. Many tools can get the DevOps job done. But this specific stack does it best for Fannie Mae, so teams are encouraged to use it.

His organization created a "paved road" of tools -- VMware, Docker, Puppet, Jira and Xray for Jira, Maven, Flyaway, Jenkins, Delphix, Selenium, Bitbucket, Nexus, Git, SonarQube, Fortify, Cast Software, Sauce Labs and Apache JMeter -- that met specific criteria. Each tool had to:

  • increase throughput;
  • eliminate waste;
  • be easy to adopt and use;
  • prove operationally efficient;
  • be coupled to a practice determined by a center of excellence; and
  • act as part of a central platform.
Your culture is reinforced by, and reinforces, your tooling and the processes you build.
Nishan SubediEtsy

Many larger companies form a tool selection committee that evolves into a centralized platform team to manage and deploy the DevOps tool stack for all of the cross-functional product teams. A centralized pipeline pays off with built-in standards for compliance and security, so the organization can enforce controls across hundreds of projects innately through the tooling, said Brennan Cropper, director of software engineering at Capital One, at Delivery of Things World.

But DevOps isn't tools, it's culture

We've focused nearly entirely on the DevOps tool stack, but DevOps is a culture composed by processes, values and character. How does that manifest in tooling?

"A strong culture can overcome any set of poor technical decisions ... weak culture can't be saved by the best technologies," said Nishan Subedi, a senior machine learning engineer and postmortem facilitator at online marketplace Etsy.

"Your culture is reinforced by, and reinforces, your tooling and the processes you build," he said at Delivery of Things World. Tools are sponges that soak up the culture of their users: Siloed IT groups will build barriers into collaboration software, and conversely, an organization that values transparency will evolve any basic DevOps tool stack to add visibility.

Meredith Courtemanche is a senior site editor in TechTarget's Data Center and Virtualization group, with sites including SearchITOperations, SearchWindowsServer and SearchExchange. Find her work @DataCenterTT or email her at [email protected].

Dig Deeper on Configuration Management and DevOps