The DevOps movement is gaining more momentum each day. But like any other popular buzzword, many companies will follow the hype and try to run before they can walk. Here are five common signs that should raise a red flag that the DevOps initiative is on a path for failure.
1. A DevOps department is created
This is the most common mistake. Many companies don’t understand that “DevOps is a culture shift or a movement that encourages great communication and collaboration (aka teamwork) to foster building better quality software more quickly with more reliability“. Instead, they think that DevOps is a job or a role, so they create a new silo called DevOps, which usually does more harm than good. DevOps is supposed to tear down silos between development, operations, and the business. Creating a new silo simply creates new bottlenecks and does nothing to solve the problem of getting to market faster with more reliable software. As a consultant, I can’t count the number of times I have heard the request to “help us create our DevOps team”. Don’t build another silo. Change the culture instead.
2. 300,000 lines of Chef or Puppet code
Another scenario I run into from time to time, and this is usually related to creating a DevOps silo, is that a team can go overboard with Chef and Puppet scripts. Instead of using Puppet or Chef to automate processes and integrate different tools together, some teams choose to “roll their own” tools. Over time they start accumulating hundreds of thousands of lines of scripts that must be managed and maintained. I have seen teams build things with Chef and Puppet that are available as services from the cloud providers. At some point you have to ask yourself, is our core competency writing Chef or Puppet scripts? If the answer is no then stop amassing huge numbers of scripts and start using tools and services that can get the job done without the heavy development effort in a scripting language.
3. Not addressing the culture change
I also come across teams that are still struggling with getting their agile methodology to work, yet they are eager to take on more change by embracing the DevOps movement. DevOps requires organizations to think differently. Hiring “DevOps” people does not get you DevOps. Changing the organization’s culture to approach software development with a lean thinking mindset is what is required. That means not only do the developers and the operations teams need to think differently, but so does the product team (the business). Somebody needs to be an evangelist for this movement. Teams need to be willing to learn new things, accept constructive criticism in order to get better, people must be empowered, and leaders must lead. Culture change is hard stuff. The technology is easy in comparison. Companies attempting to embrace the DevOps movement should invest a lot of energy into culture transformation.
4. Rewarding and incenting the wrong behaviors
This is a common mistake in any initiative that requires change. For years I have used the laundry analogy. If your kids throw their dirty laundry on the floor every day and you pick it up, they will continue to throw the laundry on the floor every day. Likewise, if the culture rewards fire fighting, people have little incentive to automate things to improve the quality of deployments and of the production software. The rewards system needs to praise people for fire prevention and discourage people from fire fighting. The DevOps movement is all about process improvement, automation, and removing waste from the system. Make sure the people are rewarded for actions that drive the right outcomes.
5. Not enough automation
When a company thinks that DevOps is a new department, that new department quickly becomes a bottleneck. When this silo becomes a bottleneck, it never gets enough time to automate all of the necessary processes for operations to be hands off. When operations is hands-on, mistakes happen, reliability decreases, and the DevOps initiative doesn’t solve any problems. Companies should be implementing continuous integration, continuous delivery, and continuous deployments. All three require a heavy dose of automation. If the DevOps initiative is not making progress towards these goals, it is time to take a step back and analyze why. After all, DevOps is suppose to remove waste from the system, not create it.
This is an eye opener and precise article. Would encourage my fellow DevOps engineers to read it.
I have met very few developers who manage to be good sysadmins, or vice versa. Whilst I can code scripts for things like nagios and munin plugins, and fix some bugs in code, I don’t do enough programming to really be a programmer. You have to be truly immersed in a programming environment to really do it well.
Also, there are very different demands on deliverables for the two roles. A sysadmin needs to be able to concentrate on security, reliability, reproducability, monitorability and resilience. Developers are focussed on shipping the latest, greatest code which mostly works.
Likewise, software testing and QA is a separate role from developers.
It won’t be many years before the concept of “devops” will be seen as a temporary aberration, a dead-end concept.
Paul, you are missing the point. DevOps is not a role where one person must be fluent at both development and operations. DevOps is a way of delivering software faster and more reliably by development and operations working closely together without silos and focusing on eliminating waste by automating everything that is repeatable (builds, testing, deployments, patching, etc.).
Mike,
DevOps is a way of delivering software faster but delivering software is only a fraction of the DevOps workflow. Like Paul mentioned, security, reliability, and resilience are also very important and have nothing to do with delivering software.
“Automating everything” is a noble goal but it only scratches the surface of an organization’s operational requirements. A lot of the “waste” that Agile advocates point to is in place to ensure long-term architectural stability, continuity of business, and efficient disaster planning.