You may not know it, but you've already arrived at DevOps Land
Installed Puppet? Visited a waterfall?... Gobble gobble, ONE OF US... ONE OF US!
After roughly a decade of DevOps hype, surely we’ve arrived at that blessed time when developer lions lie down with operations lambs in peace…? Err, not so much. Despite larger enterprises striving mightily to become more Agile (with a capital “A”), most organisations still don’t deliver on the DevOps dream, and won’t for some time.
The reasons are several, and depend on whom you ask. Funamentally, though, understanding the importance of DevOps is not the same as embracing it. As one of the key architects behind the DevOps revolution puts it, “Everyone can point to examples and data from high performance DevOps organizations, just like everyone can watch the Olympics, but not everyone is willing to put in the work to get there.”
Fighting the buzz
DevOps is roughly 10 years old at this point. Possibly older, if Leading Edge Forum pundit Simon Wardley is correct. Though Shafer, now at Pivotal, is often credited with kicking off the DevOps revolution with his 2008 Agile Infrastructure talk, Wardley points out that a “meme” like DevOps generally trails real-world practice by three to five years, giving us a launch date for DevOps in the 2004 to 2006 timeframe.
Whenever we choose to carbon date it, however, DevOps’ hype has been with us a long time, and outpaces reality as much today as five or 10 years ago. According to Wardley, it takes 20 to 30 years for a novel practice like DevOps to become “industrialised” (that is, best practice), which suggests that “we have another decade to go until DevOps firmly becomes best practice.”
Or possibly even longer.
Luke Kanies, founder of Puppet, one of the DevOps tools of choice, thinks we’re nowhere near a happy point in the DevOps evolution:
The concepts are ubiquitous, as are the job titles, but the actual practices are still barely present around the market - ask anyone to name five firms who are great at it, and especially to name five firms in the S&P 500 - and the results are literally absent. Even the best companies at software have no idea how their activities relate to productivity, which is the ultimate goal. You can see from Google’s periodic papers that they’ve just been doing random things that feel good, and they keep discovering that those random things don’t actually help much.
As such, he continues, “Everyone thinks [DevOps is] widely adopted so no one is striving any more, and as a result we’re going to be another decade or two before anything interesting happens.”
Shafer agrees. By his reckoning, “The words 'Agile' and 'devops' may have crossed the chasm, but the practices have not, which is complicated by the fact that things are still evolving at an accelerated rate.” Pressed for details, he continued:
The buzzwords precede real transformation. Devops is hard. Devops was always hard. Some have the romantic idealized notion that devops existed all of a sudden because two words got mashed together, but the reality is devops is a post facto label on successful patterns that emerged under incredible pressure to consistently deliver ever greater scalability and reliability.
That “incredible pressure” was first felt at web giants like Google. According to Mike Loukides, “DevOps was the inevitable outcome of building and operating the sites that became the web's giants.” As he notes, once a website involves “thousands of computers distributed world-wide, you can't just log in and do an upgrade. You can't give a few commands and reload the site. At this scale, automation isn't an option. It's a requirement.”
DevOps, in other words, was a natural result of web-scale. That, however, doesn’t make it inevitable in any particular organisation.
By one metric, everyone is doing DevOps, Kanies argues, yet adoption is still isolated: “Everyone has someone doing it. But no org has everyone doing it.” Pockets of DevOps somewhat miss the mark, because siloed DevOps don’t allow organisations to tap into the full benefits.
Getting to full adoption, however, is tricky.
Do as I say
One problem is that as much as vendors have tried to jump on (and pump up) the DevOps hype, DevOps isn’t something a vendor can package and that an enterprise can buy, Shafer warns. Today, most everything has been “DevOps washed,” he laments, making it hard for enterprises to figure out when they’ve arrived in DevOps land. Is it when you’ve installed Puppet? Or does just buying that service from IBM do the trick?
Neither, of course, but primarily because DevOps may have more to do with culture than any particular software. Shafer explains: “While most technology adoption requires behavior change, behavior change is the central foundation of DevOps.” Even where companies recognise the need to change, however, such recognition can’t be academic, argues Shafer: “Most orgs don't have the capacity to change behavior just from new information. There often needs to be crisis and pain together with leadership and vision. Without the first, there is no impetus, without the second, there is no direction.”
Even with enough pain to motivate change, every enterprise comes with its own built-in antibodies, ready to fight off change, however necessary. Few are noble enough to think an organisation’s greater good should take their job or deprecate their importance. So they dig in and fight off DevOps. The simple matter of squishing together development and operations for greater business agility turns out to be not so simple.
Technology matters, too
Of course, as much as culture matters to successful DevOps transformations, technology also factors in. According to Shafer, while individual tooling choices may not be critical, “Technical excellence is an underlying theme in all successful devops organizations.” This doesn’t translate to always using the latest and greatest, but it does mean organisations need to keep current with shifting trends. “A lot of the challenge is balancing the tension between focusing too much on the people or tools and the tension between the newest tools and getting stuff done,” he says. “This also makes devops an evolutionary process more than a target,” which is “uncharted territory in a lot of traditional organizations looking for a paint by the numbers solution.”
Complicating this transition is the continued mistake of framing IT as a cost center, rather than as a fundamental source of innovation. “Every aspect of human performance and experience that can be optimized by software will be,” Shafer warns. “‘IT-as-a-cost-center' acts as an anchor dragging against this optimization.”
The puck keeps moving
Unfortunately, while companies are starting to lumber in the general direction of DevOps, Wardley posts, the world has already moved on to things like Serverless. “The DevOps journey can take five to seven years,” he says, “and those who are just starting are likely to discover that once they’re fully up and running then the leading edge of the world has moved firmly into serverless i.e. they will have just built a new legacy.”
For those looking to skate to where the puck is heading, in other words, DevOps may be yesterday’s game.
Even so, with relatively paltry adoption, it’s almost certainly too soon to move on. DevOps may be passe at Google, but for your average Fortune 500 or government organisation, it’s still science fiction. Science fiction, by the way, that carries the same promise for those organisations that embrace it as it did back when Shafer first made a public fuss about it in 2009.
It could be, as Kanies says, that “DevOps is nearly to the point where Agile was a while ago, where everyone’s using all the words specifically to make their lives worse, as opposed to using the principles to make it better.” But that’s no excuse that you or your organisation need to eschew DevOps’ core principles in favor of buying into silly vendor DevOps washing. Fads come and go, but DevOps has come and hasn’t left us. We’re still talking about. Now we just need to do more about it.
We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details right here.