DevOps, as an industry term, is relatively fresh, having only entered onto most developers’ radars in the last few years. But exactly what it means is sometimes rather vague or twisted to fit the corporate mould of one product or another.
As the below Google Trends shows, DevOps has seen a steady increase in popularity in recent years, though nowhere near the explosion of interest the industry-vogue term “Big Data” has had. However, what both of these terms probably have in common is the growth is probably as much an indicator of confusion amongst exactly these terms mean as it is a symbol of increased relevance to the developer from day-to-day.
So, exactly what is DevOps?
Werner Vogels, CTO of Amazon, uttered this legendary phrase back in 2006 regarding how things run at Amazon, which I believe describes the core principles of DevOps most succinctly: “you build it, you run it.”.
“You build it, you run it” – Werner Vogels, Amazon CTO, 2006
In essence this is what the portmanteau of “development” and “operations” means. Sometimes that’s in a literal sense and the same people who develop the software operate the software. At other times it just means having the same practices in the development cycle as would be expected once it gets deployed to production.
But why would this be a good thing?
Developers tend to be well-paid, so why put them in charge of pushing the button when it blinks, which is how a sizeable majority of devs consider Operations jobs? Well, the reality of Operations, as anyone from the trenches can tell you, is often less mundane.
Operations folk get their stripes only after dealing with 2am database failures and screaming user phone calls, and a surprising amount of the time these arise due to incomprehensible release instructions, incomplete (or ‘eyeball’) testing, or the old chestnut of “well, it worked for me in dev”.
So basically, why Werner’s quote has legs is because it’s enforced dog-fooding. As an aside, I learned some years ago that the phrase “eating your own dogfood” doesn’t translate well for non-technical audiences and the grimaces of disgust tend to linger (though perhaps that was just the effect of my speaking…).
I sometimes refer to this as “packing your own parachute”. As a former skydiver, you learn quickly about motivation and quality control when plummeting to earth at 200kph and relying on the particular way you packed your parachute to stop your fall.
It’s an interesting quirk of software engineering as an industry that this is not the standard practice, really. You would not expect to go to a Michelin-starred restaurant and have a dish where the chef hasn’t tasted the soup they are serving. You wouldn’t expect an author to write a book without re-reading it at least a few times for editing. You wouldn’t trust a construction worker who wouldn’t stand on a bridge they built.
And yet this mythical barrier between development and production, brought on by bureaucratic standards and compliance check-lists, is still the dominant practice in most enterprises.
The ethos at Amazon and that in DevOps are much the same: the development is a means to an end and if you don’t end up with a parachute that actually serves its purpose, you’re going to have a painful experience. Nothing sharpens this attention to outcome like having to deal with consequences personally.
How does testing fit into this? Let’s think back to the generously-named “Flying Tailor” Franz Reichelt who discovered the flaws in his parachute suit design the hard way by jumping off the Eiffel Tower at the start of last century. Poor Franz decided abandoning test dummies at the final moment and donning the parachute suit himself was worth the risk, but, while I admire the skin in the game for the work that this attitude has, it was a mistake he only made once.
Software engineers may not have consequences quite as messy, but the lessons should be the same. If Franz had sent a succession of test dummies over the side of the Eiffel Tower with each of his changes he could have measured the impact in order to prevent one (sorry, bad pun).
For you lucky software engineers it’s easier than ever to queue up all the proverbial test dummies you need as part of the standard development process with services like TestZoo, so when it comes to donning the parachute yourself you’ve been through every scenario in testing and can simply float down into fame and fortune. Or at least in the case of Ops, a call-free sleep after your release.
With all the marketing around DevOps it’s easy to think of it merely as a fancy name for automation for the same reasons we automate anything in software, after all, that is our job. However the psychological implications of a culture of DevOps is one of the greatest benefits that can come to an organisation in adopting the principles.
A system like TestZoo can integrate into your development cycle to provide basically limitless dummies to send to their doom, to assure protection of the precious cargo at crunch-time.
What we hope to do with TestZoo is be one critical piece of the DevOps puzzle. And how do we pack our own parachute given we know we’ll have to fly it? Test it!
Tangled Wires Photo by Artist in doing nothing. 
Malfunction photo by stevenjbaker