When DevOps Goes Bad

DevOps – it's an innovative idea and intriguing proposition, that companies can improve software production and other operations by becoming more agile – by breaking down barriers between development and operations, by eliminating information silos and getting people talking together.

At the same time, DevOps isn't a thing that can be easily explained in a few words, like a linear bus or a star network. It's something that's nebulous, varied, and somewhat abstract. There's no one-size-fits-all DevOps scheme that a business can implement with a push of the button – and that's part of the problem with assuming that creating a DevOps mindset is going to be easy. There's a lot that can happen along the way in a “migration” toward DevOps models.

DevOps can accommodate all sorts of neat improvements in CI/CD and other business goals, but what about when it all goes wrong? We asked experts about things to watch out for in pursuing the DevOps philosophy. Here's some of what they said.

There's No Simple "DevOps Solution"

DevOps isn't something that can simply be implemented and then expected to succeed – a DevOps team needs the proper tools and the support of the organization. Without these, even the best DevOps pros are bound to run into hurdles.

"I think the two major downfalls in DevOps adoption are, one, mistaking the purchase and adoption of a tool as a 'DevOps solution' or 'DevOps implementation,' when in fact DevOps is really about broad changes in organizational culture and process. The tools are there to support and/or enable those changes. They (the tools) themselves are not the solution. And two, a lack of organizational support, which usually results in teams that don’t feel they have enough time to change the way they work or learn something new because deadlines are too tight. There’s an element of investment in adoption initiatives – teams are already dealing with planned work and the inevitable bits of unplanned work – but there is also the planning and management of work that goes into running a successful team/project/organization. Creating the culture, updating the processes and setting up and maintaining the tools used to support the culture and processes takes real time, and the return on that investment isn’t realized immediately. Creating the time to make that investment requires organizational support."

–Justin Rodenbostel, Vice President of Open Source Application at SPR

Tools ≠ Skills

Too many organizations try to implement DevOps by buying the most impressive tools they can find – but the fanciest tools in the world won't do any good without people who can properly use them. A DevOps team needs the right skills and knowledge before they can start to provide value.

"What we see time and again at organizations trying to implement DevOps is an approach that prioritizes tools over skills. The problem with that is you’re relying on a tool to provide your team with a capability, when you should be working to build that capability. Put it this way: If you want to be a great chef, do you go out and buy the best set of knives and start chopping? No, you take classes, you practice, you try out new dishes on your friends. Then, once you’ve got the basics figured out, go buy yourself those fancy knives."

–Robert Duffy, CEO of Ship On Day One (sodo)

Allow for Flexibility

Rules exist for a reason, but adhering to them too rigidly can hinder progress. Remember your priorities, but keep in mind that in some cases, speed outweighs preciseness.

"One pitfall I've seen from peers and other teams is being super rigid over the 'Agile' methodologies. You have to be willing to break your own rules from time to time if the situation warrants it… just don't make it a habit. The priority in today's highly competitive world is speed-to-market.

"Don't get hung up on all the checks and balances when delivering a solution ensuring each and every stakeholder has their 'i' dotted and 't's crossed. It still needs to be part of your road map, and delivery commitments.

"Whether you're going to succeed, or fail, you need to do it fast. Make sure you keep 'foundational' aspects of your environment a priority for your team (CI/CD, configuration automation, logging and monitoring framework, etc.) and make it available as a service, preach this shit at the top of the hills. Ensure the software engineering teams that are building the product can leverage your services, rather than re-inventing the wheel simply because they didn't know it existed. Learn from the experience and build upon that."

–Brent Reeves, Cloud Operations Manager at BlueCat