DevOps tool consolidation: Where rationalisation is happening
DevOps tools have a habit of proliferating. While teams are typically small, commonly between three and 10 people, according to a recent Computing survey of IT professionals in the UK and the US, they are also fairly loose, with part-time team members often drafted in when their expertise is required. And of course in organisations of any scale there will be multiple teams, each bringing their favourite tools.
Which is all well and good until it isn't. When functionalities overlap, or tools are incompatible, there's a risk of chaos. Organisations can find themselves paying for subscriptions they no longer need, and supplier management can become a real chore.
In the survey, which was completed by 192 professionals involved with software production, one third (32%) said they are planning to consolidate their DevOps toolchain over the next 12 months.
See also Generative AI: What does it mean for software development?
The category of tool most in their sights was code security (mentioned by 43% of those looking to consolidate).
Many security tools are developed for a specific purpose, or in response to a new type of threat or use case. Ultimately, though, unless they are well integrated they will leave holes - more tools does not make for more security. As more coding is done on cloud-based platforms, code security is also amenable to a platform approach. The most-used tools, GitHub Code Scanning, GitLab and Qualys are all in this category.
Organisational changes can drive consolidation efforts too. For example, as DevSecOps beds in new approaches become necessary. "We need to bring more dev responsibilities in house," said one CTO. "Need to review our security systems as current ones not working with a larger team," offered another respondent.
Cutting costs, ease of management, and compliance were the top three considerations for consolidating code security tools, with automation a close fourth.
Joint second (35%) in the list of tools ripe for consolidation were monitoring and observability and testing tools. Similarly, these are increasingly being rolled into platforms. After cost, the most cited reason for reducing the number of these solutions was, "Moving to cloud or cloud native".
"Moving to ServiceNow TSOM to leverage AI/ML service impact capability," said a platform configuration manager. "Consolidating onto one platform for ease of use," said a business applications manager.
And third was version control/source code management (33%). In terms of version control systems, there is only one winner: Git. GitHub and GitLab were the most widely used platforms, followed by Azure DevOps/GitRepo, but a fair few organisations were still using older systems like Subversion and Mercurial.
"Move all to Git type versioning, possibly in house," and "Consolidate on GitHub as part of broader adoption and cloud migration," were typical comments on plans to rationalise these systems.