Three DevOps myths - solved!

Puppet takes on the big questions from those still hesitating to adopt DevOps

Puppet took to the stage at Computing' s DevOps Summit 2016 this morning to attempt to dispel the top three DevOps myths.

Ryan Coleman, senior product manager, distilled common misconceptions into three major points, and attempted to put minds at rest over process and procedure:

1. DevOps only works with "unicorn" companies and not traditional companies like ours

Otherwise interpreted as, "I don't work at Facebook or Google, and DevOps doesn't apply to me".

Coleman argued that the above companies are considered unicorns "because they've been leading the charge with these practices".

"Maybe they haven't been speaking about it, but that doesn't mean it just applies to them. From industrial insurance companies to machine shops - everyone has the same problems," observed Coleman.

2. There's no sufficient return on investment in applying DevOps principles to legacy applications

"It's about iteration - the benefit is aggregate," said Coleman.

"You may not see those returns right away but that's okay - it's part of the point."

Coleman explained how smaller, potentially cheaper changes to legacy technology can create obvious immediate benefits.

"You can take all software and put it in version control - you can just have one file per server," he offered as an example.

"So now you have a central source of truth [for each system] - start looking at those at your leisure. You'll find they're not quite the same - but why aren't they? Should they be? At least now you know the questions to ask."

Helping to automate change, rather than doing it manually, "can save you time in the long run," said Coleman.

"It's not like if you reduce workload on people they just go away - they can move on to the next legacy app, or the next new project," he said.

3. DevOps requires spare time and people we simply don't have

"You don't have to spend six months on a DevOps project to see any returns," advised Coleman.

"One thing I'd encourage you to do is not start by saying, ‘We made manual changes to our service today, maybe we've got some script in place - let's move immediately to continuous releases every day'.

"Because if you set out to plan that project, it will take six month, or even years, and you'll just get demoralised. You won't see the return till you're all the way there, and that's not even your biggest problem anyway."

Coleman suggested that a company could start small, by aligning routes, carrying out version control and starting to automate changes as the process unfolded.
"Then start getting to a point where you're pushing code and deploying. It's not about spare time," he said.

"Also, you get to reinvest that time as well. All those changes you're no longer manually distributing to 17 servers is five minutes you can spend on the next task."