DevOps Tool Sprawl, Part 2: Winning the Battle Against DevOps Tool Sprawl
This blog continues our exploration of the growing issue of DevOps tool sprawl. Tool sprawl risks burying the intended benefits of DevOps generates into a costly layer of under-optimized tooling.
A broad set of capabilities are necessary for supporting a prototypical DevOps-aligned strategy in a large enterprise. The array of core tooling functions necessary for supporting this paradigm include:
- Automated Build
- Automated Testing
- Configuration Management
- Performance Monitoring
- Virtualization Management
- Cloud DevOps Management
The market offers a bevy of options for supporting each of these capabilities. Some tools are part of suites intended to facilitate nearly all phases of DevOps. Others are highly specialized tools targeted at narrow but pressing DevOps management needs. Open source tools, meanwhile, mature into an increasingly vital part of this mix.
Complications from Tool Acquisition and Planning
To make matters more complicated, tools that support this varied functionality have often been implemented piece meal in a DevOps architecture that varies across business units and development teams. Moreover, each team is often on a different timeline in their transition to DevOps workflows. They acquire new tools when encountering new challenges, often not checking with others to prevent unnecessary acquisitions. This results in tool sprawl across the enterprise.
Decentralized DevOps tool planning can lead to a situation where there’s little rhyme or reason to the organization-wide DevOps tools strategy. A survey conducted by DevOps Digest suggests that “82% of [new tools being utilized] are outside of the officially supported stack.” The larger and more decentralized the organization, the more difficult it becomes to ensure standardized adoption of DevOps tools across the company.
Building an Informed View of the DevOps Toolchain
Consequently, enterprise technology leaders seeking to rationalize their DevOps portfolio face a challenge simply in building a bird’s eye view of overall DevOps tooling—much less rationalizing this portfolio. To generate an informed perspective on the current DevOps toolchain, manual work is necessary and can be an overwhelming (and costly) chore when faced with this sort of environment.
Yet, this analytical perspective is absolutely essential for rationalizing DevOps across the organization. Without detailed, real-time perspective on existing costs, capabilities, gaps, and overlaps, planning for a better DevOps strategy is impossible. Lingering issues in any given one of these areas introduce cost bloat. These issues slow the transition to “speed-of-business” app and feature development that DevOps seeks to institute in the first place.
Here’s the key: understanding that solving this brand of tool sprawl through the brute force method of manual review is woefully inefficient, if not virtually impossible over the long term. The number of features and costing scenarios inherent to this analysis is truly immense (and constantly changing). And comparing current capabilities to alternative scenarios increases the complexity of this analysis dramatically.
Curiously, the most powerful solution to DevOps tool sprawl is one final tool (a platform specifically designed to optimally manage a complex enterprise IT tools portfolio). In Part 3 of this blog, we’ll take a look at what IT leaders need to untie this knot and unlock the efficiencies of a rationalized DevOps transformation. A systematic approach to monitoring, managing, and optimizing the DevOps toolchain is an imperative for breaking through this technology management dilemma.