While DevOps practices may be spreading throughout organizations both large and small, often times the most visible success stories are also the most exceptional. Organizations like Netflix, Etsy and Google are brought up in conversations about DevOps time and again because they offer the most stark examples of the benefits that the model can bring to businesses. But the scale of their operations can often be intimidating to the everyday IT person.
“People will tell me, ‘Well, these are unicorns—special companies. We’re not like that. What works there will not work here,'” says Jez Humble, a principal for the consultancy ThoughtWorks and co-author of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. “I think that’s a fallacy.”
According to Humble, two phrases that he hates the most as excuses for not adopting DevOps or continuous delivery principles are ‘That can’t work here,’ and ‘But we’ve always done it that way!’ He’s one of a growing contingent of DevOps pundits who argue that it is plenty possible for even the most run-of-the-mill organizations to engage in DevOps.
“DevOps is also for horses,” says Gene Kim, author of The Phoenix Project. “In fact, every unicorn was once a horse. Amazon in 2001, Google in 2004, Twitter in 2009 and LinkedIn in 2010—they all had huge monolithic code bases and inconsistent deploys.”
Humble agrees that these so-called unicorns “have the same problems as everyone else.” But no matter how remarkable the scale of their solutions to those problems, other organizations should be able to learn at least one very valuable lesson from their case studies.
“The critical piece is they’re always working to improve what they do, and that’s something that works everywhere,” Humble says.
That’s Nick Galbreath’s philosophy. As the former director of engineering at Etsy, Galbreath saw first hand the transformation that the organization was able to make using DevOps patterns. He’ll assure any organization that it didn’t all happen in a day. Which is why when people ask ‘How do you get started with DevOps?’ his answer is simply to start.
“If you have a sympathetic management ear, ask ‘Why don’t we try to cut deployment time in half?'” says Galbreath, who is now the vice president of engineering at IPONWEB philosophy. “Because the other way is to say ‘Deployment time takes too long, let’s do half as many.’ Wrong direction.”
Setting up a goal like cutting deployment times in half will get an organization streamlining and weeding out junk processes. It’ll also have the team working to move those processes from inside a select few peoples’ heads and into things like a batch script or even just a simple document so that they’re easily repeatable across the team and that more can be done in parallel.
“Cutting that work that adds no value in half, you’re really going to empower your group and your team to come up with innovative solutions,” he says.
In a similar vein, DevOps for normal folks could also be chunked up incrementally on a project-by-project basis or automation tool-by-automation tool basis, says Josh Corman, CTO of Sonatype.
“You don’t have to do an enterprise-wide shift hard left to DevOps,” he says. “You can do it in little projects or little small automations that free up time so you can achieve more competence.”
In addition to incrementalism, Humble suggests providing a leadership environment that encourages taking chances and learning from mistakes.
“Create safe situations so that when people make mistakes we can actually learn from them rather than engage in finger pointing,” he says.