Sponsored: Creating the Storage Advantage
Opinion Is DevOps actually a thing, or just the latest funny way to case a word? At least there are vowels in it. We finally know the proper casing, but is it actually something normals are doing?
Right after the cloud horses left the barn some years ago, this mysterious notion of "DevOps" surfaced. DevOps started as a rallying cry around doing something with the combination of agile software development, lean manufacturing theory, and using new automation technologies like Puppet and Chef on top of cloud platforms.
More ReadingErik Meijer: AGILE must be destroyed, once and for allChef and HP cook up partnership for infrastructure as code – even on WindowsPuppet-wearing devs: There's now an app (or two) for thatIf you like slipping your hand into Puppets, look for these certified typesSMBs are tumbling into the cloud? Oh get real
The goal was to get "10+ releases a day". The famous Velocity 2009 presentation claimed this was not only possible, but common practice in their shop.
The idea of releasing code to production more frequently is certainly appealing, and who wouldn't want to do that in the age of constantly updating mobile apps? Since then, those one-per-cent elite West Coast kids have dug into DevOps like worms into a pile of fresh trash. Clearly, in the consumer space which sucks up most of the IT world oxygen, DevOps looks valuable, but what about for the rest of us in the normal, enterprise space?
Using job postings tracked by Indeed.com as a crude yard-stick, you can see a dramatic uptick in hiring interest:
What is DevOps?
Beyond this kind of crude measure, us prognosticators at 451 Research wanted to dig into the mainstream DevOps market deeper. To that end, we just finished polishing up a survey of 200 DevOps and DevOps-minded individuals. This has given us a better sense of how immature the DevOps market is. Don't get me wrong, there's certainly interest, and the field has clear value, but a few of the chestnut theories of what DevOps is and how it's practiced are far from fully baked and deployed. Indeed, there's a lot of room for improvement.
Whether perfectly accurate or not, our premise was that the primary driver of doing DevOps would be to reduce cycle time: to get code into production sooner. On that point, the study participants seemed to agree, and the industry is doing much better than we'd have expected.
48 per cent of study participants deployed software at least monthly, with 22 per cent deploying weekly, and eight per cent deploying daily. With near half operating on a tight 30 day cycle, it's not surprising that half of the group was satisfied with their release frequency, meaning that half would like to get software out the door more frequently.
Why bother with this hassle, we asked? Mostly because of business demands – not just shiny object syndrome or some cruel coder callisthenics.
Our analysis of these results is that business demands rank first. Competitive pressure, business productivity demands and revenue demands total 51 per cent of responses. Product management demands – improving functionality and delivering new features to users – are a good secondary driver, indicating close attention to end-user needs. These are, of course, great goals for software to have: make money and delight users. Sign me up!
How's that duct tape holding up?
When you talk with DevOps cognoscenti, they like to pull out this giant hammer called "culture" that they promptly use to bash out your brains if you try to talk about actual tools. "Tools are not the issue, meet my hammer. I call it 'culture.'" They go on and on about culture, and process. It's delightful and necessary, I suppose, but it belies the sense that there's a "DevOps toolchain" out there: a common collection of tools and practices that teams use to get the job done. To that end, we strapped on our best Bascinet and asked about the tools used. Here's where things were less than utopic.
Spinning the vision dial way up, in the ideal DevOps toolchain it feels like you'd see at least two things.
First, consistent use of modern model-driven automation tools like Puppet, Chef, Ansible, and Salt throughout development, QA, and production to model, deploy, and manage the application. You do this to reduce the amount of changes and manual work needed between each stage as part of the process of reducing the "wall of confusion" between development and operations. But when we asked our study participants what they used, home-grown processes and golden image generation handily won:
It's rare to come across a "build and installer team" that doesn't protect their growling, home-grown ball of duct-taped cats like it was their own child, we know. But: really, that's probably not something you should be doing on your own. Snowflakes, unique and special as they are, tend to melt when the heat is turned up.
Second on the vision-questing, you'd expect DevOps teams to be using some sort of continuous integration tool, a Jenkins-type system, if not Jenkins itself. Here, things are bit more cheery, but that ball of cats pokes up as the winner again:
That 28 per cent of respondents who aren't doing any sort of CI is the most shocking. Surely things would improve for that lot with a bit of CI.
One can be cynical at this point (hello, dear readers!) on all of this and write DevOps off as sheer fantasy. On the other hand, after poring over our study and injecting it with a healthy dose of our anecdotal “evidence,” it's more accurate to say that DevOps, as a mainstream concern, is very early. There's clearly a desire there, but getting everyone on the same page, toolchain wise, is far off.
As in software development, the good news is that people are willing to pay for these tools. In the case of model-driven automation and CI tools, well over half of respondents said they were willing to consider putting their hand in their pockets, if they didn't already.
Free is nice, of course, but DevOps as a movement won't fund itself: untangling those build and deployment wizards from all those duct-taped cats isn't going to be easy. ®
Sponsored: Creating the Storage Advantage