DevOps: You’re doing it wrong

IMG_2105.jpg
IMG_2105.jpg (Photo credit: lambertpix)

Each time a new software development trend appears, people manage to find a way to misinterpret it so that it looks like a shortcut -- typically, because this is far easier than really understanding the idea in the first place.  Invariably, these shortcuts fall flat on their faces -- perhaps contributing to the "trough of disillusionment" in Gartner's hype cycle.  I saw this when people did procedural coding in an object-oriented language and called it OO, and I saw it when people thought they were "agile" just because they had a daily stand-up meeting.  I've even seen it when the stand-up meeting was held sitting down.

Now, it's DevOps.  In much the same way as Agile doesn't mean you don't have to understand software requirements, DevOps doesn't mean that you're getting rid of your Operations team because your developers are doing their jobs for them.  In "DevOps: The Future Of DIY IT?", readwrite points out a Gartner survey that shows that NoSql databases are generally being administered by developers -- not DBA's -- and projects out of this a future in which developers are running everything in production.

There are a couple of gigantic holes in that argument, though.  First, I'd bet that if companies had DBA's that knew the first thing about administering a NoSql database, they'd put them to work.  Instead, these tools are so new and so immature that the tooling is still be invented, to say nothing of procedures.  The second big problem with this over-generalization is that when developers are administering NoSql databases (or any other production systems), they're not developing applications, quickly leading to a very expensive Operations staff.

That ain't what DevOps is all about.

The goal of DevOps is to see developers and operations working together to create a virtuous feedback loop -- just because they start acting like they're on the same team doesn't mean that either of them are going away.