A commonly held concern is the idea among enterprises that pursing a continuous delivery approach to IT code deployments increases the risk of something going wrong.
Caroline Donnelly reported from the recent DevOpsDays conference, and found that experts believe the reverse tends to be true.
Kris Saxton, principal consultant of Automation Logic, said during his time as a systems engineer, his anxiety levels tended to rise the longer a piece of IT kit he was responsible for remained up and running, before going on to experience “post-intervention relief” after the inevitable outage occurred.
“Moving to smaller, more frequent releases gives you that feeling of post-intervention relief more frequently because you’re not playing with massive bombs anymore,” he said.
This sentiment was shared by several other speakers at the event, including DevOps enthusiast and Tripwire founder Gene Kim, who shared data showing firms that use DevOps tend to deploy code changes 200x faster than those who do not.
“When something goes wrong, the mean time to restore services is usually 168 times faster,” he added.
Getting to a point where an organization is able to securely and efficiently roll-out multiple code changes a day often requires firms to undergo massive amounts of re-organization to create multi-disciplined and collaborative teams, populated by developers and IT operations staff.
This can prove off-putting for senior management-types who often get final say on these types of projects, unless the department pushing DevOps can demonstrate value from adopting it.
However, without buy-in from senior management, IT departments may struggle to get their DevOps ambitions off the ground on a company-wide level.
“Interest in DevOps is widespread at a grass roots level, but there is arrested development for that to spread in a meaningful way without senior management sponsorship,” Saxton said.
“Otherwise, you can innovate in a local sense in your silo or team, but you’ll not be able to connect it up to other services to make it meaningful. Your development efforts around innovation will wither and die in the long run because of that lack of innovation and sponsorship.”
To get the ball rolling, Saxton said IT departments should embark on a small-scale DevOps trial to begin with, before sharing the results of this endeavour with senior management.
Metrics to back the point that DevOps can make a difference to the way the organization is run are important to share here, but they must be presented in a business-savvy way.
“You’re persuading senior management this is something worth doing, so you have to do so in a way and a language that makes sense to them,” he said.
“For example, the main benefit from DevOps to a development team might be the ability to move quickly, but it might work out better [to pitch] it as reducing Opex [operational expenditure]. Both statements are true, but you need to tailor the message to your audience.”
Regardless of how exactly you do it, enterprises must implement DevOps or risk missing out.