Go DevOps before your bosses force you to. It'll be easier that way

Some people are making very bold claims about what DevOps can deliver. Here’s one: “High-performing IT organizations deploy 30x more frequently with 200x shorter lead times; they have 60x fewer failures and recover 168x faster,” according to the first bullet point of the 2015 annual Puppet Labs State of DevOps report.

With claims like those, managers in all sorts of organizations are starting to sit up and evaluate “doing the DevOps.” And it’s time to worry.

That’s because, inevitably, those considering and then mandating a new DevOps direction will invariably have different interpretations of “what is DevOps”. The desired goals and ways of getting there will be shaped by this understanding and follow from there. For better, or worse.

The problem is magnified because once a new idea has taken root and gained buy-in at executive level, challenging it is nigh on impossible – until the inevitable train wreck happens.

If you are in an organization where DevOps is in the air it therefore behoves you to make sure the management fully understands what DevOps entails, and especially understands that it’s not a quick win.

No quick win

Unlike virtualization, which became a quick way to save money with capacity management optimization, DevOps is not simply a technology that one puts into place to optimize an existing way of operating. DevOps – and the broader “cloud native” approach to custom written software development and delivery – is about changing how your organization functions, often along with which tools its uses, to drastically improve your software. You don’t get eye-popping results like the Puppet Labs’ reports by simply twiddling some knobs in the stack.

So, before you embark on your DevOps quest, it’s good to make sure your organization understands what DevOps is and ensure that it is fully – nay, smartly – behind it. It’s all too easy to launch DevOps programs based on misconceptions. Let’s look at three of the more common ones that are easy gut-checks.

DevOps is automation

The most common misconception is that “DevOps” means simply the use of Puppet, Chef, Ansible, Salt, or one of the other new automation frameworks. While much of the early history of DevOps is inextricably tied to these automation technologies, their use is, at most, merely necessary but is not sufficient for full DevOps.

Instead of just automation, DevOps also includes a very evolved agile style to product development. Software development is in the name. Without a mindful approach to improving the actual software being developed, you’re merely automating eventual failure – or, at best, mediocrity.

The creation of a DevOps team

One of the more pernicious DevOps misconceptions is the need to create a separate DevOps team. The counter-point, here, is that “DevOps” is an end-to-end approach to improving your organization's software: from product management, to development, to QA, to deployment, to operations.

One of the chief theories of DevOps is that separating out the roles – and, thus, people – in that full process introduces more damage than “savings”: each role ends up locally optimizing and losing sight of the big picture. Hence, the constant barrage of “worked in dev, now ops' problem” slides in DevOps presentations. These separate silos also introduce “waste” in the form of the communication between teams as software moves through the various life-cycle “gates”. Adding yet another team introduces even more waste.

The notion that a separate team, or person, handles all the DevOps related concerns belies a misunderstanding of what DevOps is at its core: sweeping changes to how the organization operates, end-to-end.

DevOps will save you money

Coming from a decade of near alchemical cost savings from virtualization, IT management is conditioned to think first about cost savings. When it comes to new technology adoption measuring savings is the easiest, most dramatic, and, thus, most addictive way to show ROI.

DevOps at first seems to have the trappings of a great cost savings initiative. The idea of having “one team” feels like you’re reducing head-count. When crossed with the idea of a “full-stack developer” – those mythical beasts who can code and do systems management like some short order cook whose skills range from flapjacks to foie gras – management can quickly start to salivate at the ideas of getting more from less staff. Confusing DevOps with automation can add to the alluring mirage just over the horizon’s edge of quick-savings.

While I would argue that cost savings do result from a mature DevOps-driven organization, they certainly won’t come in the short term, nor will they be easy to model up-front. The “savings” are in things like quality of software and better uptime in production. These types of savings are all about “sucking less,” which doesn’t exactly model well in a spreadsheet.

Be the baby, not the bathwater

We’re very close, if not right at, the apex of DevOps’s “inflated expectations.” This year and next, I’d expect almost every organization to start asking the question: “How can we benefit from DevOps?” and putting “strategies” together to do so. The prognosticators at Gartner are predicting DevOps project failures at a rate of 90 per cent by 2018.

If you are part of staff who’s responsible for implementing management decrees, now is the time to ensure your organization doesn't get saddled with some misconceived implementation of DevOps. You – and your organization – want to be part of the 10 per cent, not the 90 per cent. It’s up to you to make sure that should any bathwater get thrown out, the baby of DevOps doesn’t go with it. ®