If you are anything like me, at this point, you’ve heard lots and lots about the DevOps movement. Like so many other things in this world (“quality” and “architecture”, for example), DevOps is a term that everyone grasps immediately, everyone is sure what it means … and if you ask five people, you’d get six different answers.
Today, I’ll take a brief stroll through the concept, probably get shouted at in the comments, and eventually we may actually get somewhere. (This follows Heusser’s Rule: When other people can’t define something, tell them what you think it is, and they’ll be happy to correct you.)
Here’s my short version: Take a virtual environment that you can script – writing code in, say, Python to create new servers. Pull that code from version control, and have the creation happen automatically. Now integrate that into the build process, and automate enough checking that you have some confidence the build is reasonably acceptable. Combine that with serious real-time production monitoring and the ability to have one-click rollback. Suddenly you’ve automated build/deploy, some of test, and provisioning, turning “Ops” into a programming task.
That’s DevOps … at least according to this book. (Or my simplification of it. There’s a lot more to it, for example the use of config flags to turn features on and off without less formal change control. Check out the book.)
There are other places to go to learn DevOps; The Phoenix Project is a business novel about transforming an operations group. Where “What is DevOps?” stresses scripting the environment, The Phoenix Project starts with tools to bring general IT, development, and test teams together, visualizing the flow of the work, limiting the work in progress, and aligning the work to hit goals, instead of talking in terms of SLA’s and ticket systems. The Phoenix Project does have a few pages at the end of the book about virtualization and automating provisioning, but it is not the focus of the book.
This means to me that DevOps is at least two things – both ‘working closer together’ and also this idea of automating the traditional ops role. (Provisioning, deploy, rollback, monitoring, and so on.)
All This Stuff Sounds Cool … But Is Anybody Doing It?
While there have been some wildly-hailed success stories with DevOps, most of them are new companies without a traditional IT infrastructure, selling bits for free and making money on advertising – companies like Flickr and Twitter. Etsy, in New York city, is probably the best-known DevOps success story that actually sells products and deal with customers money. Starting in only 2005 with no legacy systems, and not having to do order fulfillment, Etsy’s environment was certainly more easily adapted to a DevOps approach than most.
While I can’t claim statistically-valid research, I have been talking to people about DevOps for the past few months, in my capacity as a writer, consultant, and conference speaker. When I talk to people, I tend to get one of three responses:
(1) “What? Oh. Yeah. That sounds cool. Must be nice.”
(2) “Oh yeah. DevOps. We are studying that.”
(3) “DevOps? Of course. We started a DevOps group six months ago.”
Now the first answer, I understand. The second I find fascinating, because it can mean so many different things. “We are studying that” could mean there is a funded company initiative. It could mean that somebody read an old copy of InformationWeek they saw lying around, or that some executive is championing the idea, and the department is waiting it out.
That third answer may just be the most interesting of all.
What Do “DevOps Groups” Do?
When I ask what these groups do, nine times out of ten, my friends usually tell me that the “new” group is what I would call a “Production Application Support Team”, with a variety of skills, able to push code to production, debug and support issues in production, and sometimes even make fixes. That’s great, but it doesn’t come close to the promise of the original book by O’Reilly – and it isn’t the vision of the existing groups working together as one team that I see in The Phoenix Project.
This makes me … confused.
This leads me up to last week, when I got an email in my inbox from CA, the company formerly known as Computer Associates, offering a report to tell me “What Smart Business Know About DevOps” along with a survey of the industry. I was intrigued.
39% of companies surveyed claim to have already adopted DevOps.
Folks, I’m sorry. I routinely interview the most progressive companies in software development. In the past year or so I’ve been on-site at Zappos, Groupon, Royal Caribbean, Intuit and Geoloqi (now a division of Esri), along with the folks at a half-dozen conferences, and polled my contact network.
These are folks that have budget and are open to new ideas.
And no, a third of them aren’t doing DevOps – at least not doing DevOps according to O’Reilly – not infrastructure as code.
Which brings me back to those three different answers I got, and the separate and distinct “DevOps Teams” that I’d be more comfortable calling “Production App Support” Teams.
It might be more accurate to say that 39% people surveyed have IT departments that are doing something and calling it DevOps.
I am convinced that automated build/deploy and provisioning is valuable, and the future for many organizations.
For now, though, I suspect it is just that: The Future.
Am I wrong? Let me know.
This is my first word on the subject; it may not be my last.