Comment If you are a data centre provider with a new DevOps division that is actually just two blokes sat in a call centre who kind of know what DevOps is, then you're probably not doing DevOps.
Also, if your DevOps toolset doesn’t include quantifiable tasks metrics and call stack analysis technology, then that's probably not DevOps, either.
The point? There’s a lot of BS in this space – it’s almost like we need a DevOps bullshit detector.
DevOps has become the illegitimate child of the IT industry, with every vendor from A to Z claiming to have fathered some of its DNA. Instead of DevOps being carefully refined and honed as a culture and practice as it should be, we have instead witnessed a kind of “cheapening”, which has in turn led to a prostitution of the original concepts it embodies.
Let us remember that the portmanteau itself is only the genuinely new thing here. Developer (Dev) and Operations (Ops) issues have been the focus of programming-purists since way before the turn of the millennium.
Throwing the code over the wall
Firms like IBM, with its Rational brand, have been talking about “throwing the code over the wall to ops” issues for many years. Yes, OK, DevOps is more than configuration management with version control and build management support (clearly we are referencing IBM Rational ClearCase), but these functions are its foundations and they deserve not to be ignored.
Here’s how your DevOps BS detector should work...
Customer: Hi, I need DevOps to unify my code shop and operations efforts.
Vendor: Great! We really do DevOps, I mean really!
Customer: Phew, OK... do you offer granular testing tools that test individual code methods with peer review tracking and merge conflict management functions to handle multiple code-commit scenarios?
Vendor: Umm, not so much.
This (obviously fabricated and exaggerated) example is a case in point. Yes, some firms claim to do DevOps and the company has been talking about “autonomic computing systems” and the regulatory management of the software application lifecycle for a generation now. But no, your average Johnny-come-lately firewall specialist Security-as-a-Service vendor really probably doesn’t.
What the DevOps bullshitters typically have is either:
- As already suggested, some kind of support service with an appreciation for application development issues
- A washed up bunch of sysadmins and DBAs who thinks they know how the finer points of operations should work in the 21st Century
- A new DevOps logo that looks pretty, but not much else
A throwback to the mainframe era
Self-styled DevOps purist Ben Wootton is now vice president of technology for Europe at Sendachi. “We didn't need DevOps 20 years ago,” he declares.
“My great grandfather told me it was how the mainframe guys worked. But then the suits turned up in IT and put all of these structures, process and procedures into place – stuff like ITIL. At that point all the collaboration and the fun came to an end and we all stopped talking and started just filling in tickets to each other. DevOps is a label for undoing that bureaucracy and getting back to how we used to do things.”
Wooton thinks that real DevOps should incorporate restructuring an organisation and its office space – i.e. getting your developers and your ops team sitting in the same country at least, and then trusting them to get on with things.
“That will be far more effective than putting any tooling in place – even call stack analysis – but it's one of the last things most companies are ready to look at,” he asserts.
Colin Campbell is director of technical content at configuration management and release automation specialist firm Chef. Campbell explains very clearly that: “From a tooling perspective, automation (and I mean automated testing), continuous delivery and full stack integration – both with regard to external technologies and within the application and infrastructure stack itself, are key pillars of the DevOps workflow.”