About a month ago I posted a link to the DevOps Group on LinkedIn. The linked blog post responds to Donnie Berkholz's assertion that DevOps has not been widely adopted outside of San Francisco Bay area startups.
Comment notifications immediately began streaming into my inbox. About half the comments (38 as of today) strenuously disagree.
Judging from the comments, and a couple of extended Skype conversations, it looks like DevOps practices and culture are alive, well and growing in many areas outside the Bay Area startup scene.
Where is DevOps? All over the world, in startups and enterprises.
People affirming the wider adoption of DevOps wrote from Brazil, Canada, India, the Netherlands, New Zealand, Spain and Sweden.
Mark Elszy, a client relationship executive with Computer Sciences Corp., commented, "There is increasing interest in DevOps as well as a number of openings on job sites on the east coast." Others agreed that DevOps is gaining traction in non-Silicon Valley cities such as Boston, Cleveland, Phoenix — and in Portland, Ore., where we're headquartered.
People from bigger cities report the most awareness of DevOps, probably because there are more technology companies in these locations.
My friend Karl Matthias, an IT operations pro who’s been living and working in Germany and England for the past few years, said DevOps is more widely prevalent in startups because they have less hierarchy and can move faster than bigger companies. He also thinks DevOps adoption is spreading quickly in the worldwide tech startup community because it’s so small — just a couple hundred thousand people. “We know each other and we talk to each other about what we’re doing” to solve specific problems, Karl said.
Others say DevOps is de facto for startups because most can’t afford the luxury of separate operations staff. Of necessity, developers are charged with managing infrastructure. Given their skills and background, devs naturally treat infrastructure as code. That tendency is reinforced by the common practice of using Amazon Web Services and other cloud services for testing new code.
Yet some commenters pointed to big companies as drivers of DevOps.
Big companies seeking a competitive edge often look to continuous delivery, and that moves them to adopt DevOps practices, whether or not they call them by that name. Some well known examples are Amazon, Etsy, Google, Netflix and PayPal.
DevOps by any other name is just as effective
When an innovative approach to begins to take hold and gets its own name — for example, lean manufacturing, ITIL, Agile or DevOps — folks who have been in the industry for decades point out that people have already been doing the new thing for quite a while, without giving it a special name. Some LinkedIn commenters pointed this out.
Don’t call it DevOps!
Some well-known DevOps leaders object to the term being used to label people, job roles or teams. Jez Humble, author of Continuous Delivery, pointed out the dangers of creating a DevOps team: “The Devops movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems.”
Patrick Debois, a Belgian consultant who’s often called “the father of DevOps,” said in a recent Skype conversation that using the term “DevOps” often triggers unrealistic expectations in an organization. “They think, ‘we can do 20 releases in a day,’” and when that’s not quickly achieved, “it gives DevOps a bad name.”
Patrick said he’s seen the focus on faster code throughput overshadow one of the most important elements of DevOps: the culture of active collaboration between developers and IT operations people. That’s partly due to the fact that the term DevOps is now being used as a sales tool.
“There’s a big opportunity for big IT companies to support collaboration,” Patrick said. “But the promotional material is around rebranding tools, around tracking and releasing [code]. It’s not around changing how they or their customers work.” Some refer to this kind of marketing as “DevOps washing.”
And some don’t call it DevOps at all
Richard Cross, a freelance IT consultant, pointed out that banks, for example, are implementing DevOps practices without labeling them as such: “Managing Infrastructure as Code" (to the point where you recreate your entire Dev/QA/UAT environments every day or on demand), fully automated Continuous Deployment pipelines to Production, Kanban and of course close collaboration between Development and Operations…”
He also points out that some DevOps practices depend on newer automation technologies, so “if it feels like things you were doing 10 years ago, you’re probably not doing DevOps.” Which raises the core question:
What is DevOps, anyway?
It may be most reasonable to say DevOps represents a shift in thinking and culture. Instead of regarding software development and IT operations as separate entities, the DevOps perspective considers them as areas of technical responsibility, taken on by people who work closely and collaboratively towards the same purpose: faster release of software that fulfills business requirements and goals.
We’re interested in your views on DevOps. Please share them in the comments section below.