Why DevOps Fails: A Closer Look
by Sylvia Fronczak
DevOps promises greater innovation, speed, and automation—along with a more engaged and motivated team. With this list of benefits, many organizations are working to bring DevOps to their teams. However, with all the companies jumping onboard the DevOps transformation train, there are still many cases in which the transformations fail.
So what can we do to ensure that our DevOps implementations take hold? What should we look out for that could go wrong? Let’s take a look at the different reasons why DevOps fails, so we can take some of these warning signs and make sure we don’t fall into the same traps.
Not Considering the Big Picture
When considering a digital transformation of any kind, one common mistake involves not considering or even defining the big picture. And this picture should go beyond developers and operations—the entire organization should have the same shared understanding and vision for the DevOps transformation.
Does this mean that every team must implement DevOps the same way?
No. That might not even be possible. As you may know, there are many ways to implement DevOps and many tools you can use. However, depending on the software, age of infrastructure, and other considerations, it may not make sense to have exactly the same tool or process for every product.
So although it’s common for some teams to take a slightly different path toward DevOps and possibly use different tools, there should still be a shared vision across the organization. Therefore, if everyone in the organization drives toward the same vision and goals, we can still get what we need out of the DevOps transformation.
Not Talking About Cross-Team Collaboration
With larger organizations, some amount of siloing is inevitable. Whether it’s separate products or thin slices of functionality in a larger product suite—or even different operational functions like infrastructure and data—one team can’t do it all. And although DevOps encourages teams to own their own operations, that’s not always feasible on day one. It might take a while to get to the point where operations and infrastructure can be handled by a product team.
Now, how does that relate to your DevOps transformation? There will almost always be dependencies between teams, so you’ll have to consider cross-team collaboration and implement solutions that automate processes between teams. For example, if a software team automates its own processes, but has to rely on ticketing systems to get infrastructure changes made or JIRA tickets for database changes, you’re simply moving bottlenecks to different areas.
Part of the DevOps transformation should involve improving cross-team collaboration and coordination so that product deployments aren’t blocked by external teams with different priorities.
Trying to Transform Everything at Once
We can’t go from no DevOps to deploying each application multiple times a day. We have to take it slow and consider how we’ll evolve the solution over time.
In the same way you’d handle refactoring a software application or decomposing microservices, start with a product or process that’s not the most critical. Start at the edges of the development pipeline, where new processes and tools won’t be as disruptive. And find use cases where you can solve pain quickly, so that benefits are quickly realized and motivate additional changes.
Then take the lessons from that implementation and improve on the process. Make small, iterative changes as you spread the knowledge and processes to the next team.
Not Using Metrics or Measuring Results
DevOps is more than just release and deploy. Without gathering metrics on what deployed and when, you’re just shooting blindly and hoping automation saves the day. As we drive toward continuous delivery, we must add objective metrics that clearly communicate the health of our system. Measure & Improve, think DevOps Value Stream Mapping.
Without metrics, we might miss small failures that need to be corrected quickly. This can decrease the confidence of everyone involved in the transformation process.
Forgetting Important Components
When looking at DevOps, most companies focus on software and the CI/CD pipeline. It’s OK if that’s where you want to start, but you also need to pay attention to other parts of the pipeline.
First, if you can’t roll out and roll back infrastructure changes automatically, then you have the same problems you originally did with your software. Although you won’t get there overnight, strive toward environments that you can spin up and down without difficulty.
Next, companies often forget data. They consider data to be this static, untouchable thing, but data should be considered in the automation pipeline as well. As with infrastructure, it may be hard to get here overnight, but thinking about the state of data in new ways will make your products more resilient to failures.
Lastly, we must consider automating testing as much as possible. If we really want to deliver code more frequently, we can’t rely on manual testing. That will only create further bottlenecks in our QA team when we’re shipping code to various environments daily or weekly.
Not Considering the Culture
DevOps is more than just software and tools. One big component of DevOps success that goes beyond automation involves people and culture. It’s not enough to have all the DevOps tools and processes. The culture needs to be one of continuous improvement, feedback, and reflection.
And this culture change can’t be segregated to just developers and operations. This is a change that involves the whole company, because if you’re going to release products faster, then it’s not just your developers and ops that are affected. QA needs to be on board. More testing needs to be automated. Support personnel need to be up to date on what’s going out and when.
So, what makes up a good DevOps culture across the whole organization?
- A culture that allows for mistakes while finding the best path forward.
- The ability to explore improvement opportunities.
- Blameless retrospectives on what’s going well and what still needs improvement.
- Communication of successes and failures to the whole organization.
- A drive toward continuous improvement.
Without these components, we can go through the motions of DevOps, but we won’t be driving innovation and delivery as well as we could be.
Find What Works for Your Organization
There are many reasons why DevOps fails within organizations, and these reasons are affected by existing practices and culture. It’s important to take a look at the big picture in an objective and caring way. Then we’ll be able to make changes and improvements to move us toward success.
Furthermore, it’s not a definite sign of failure if you see some of these problems in your organization. Consider what your particular pain points are and strive to correct those first.
And finally, keep in mind that a DevOps transformation is never truly done. Different companies may not be able to solve all automation problems using DevOps. Iterate on solutions to improve the processes and culture every step of the way.
01 JULY, 2020 by Diego Gavilanes Ever since the dawn of time, test environments have been left for the end, which is a headache for the testing team. They might be ready to start testing but can’t because there’s no test environment. And often, the department in...
29 JUNE, 2020 by Carlos Schults In today’s post, we’ll discuss data literacy and its relevance in the context of GDPR. We start by defining data literacy and giving a brief overview of GDPR. Then we proceed to explain some of the challenges organizations might face...
23 June, 2020 by Arnab Roy Chowdhury In this digital era, online businesses have become mainstream. Consequently, online commerce has flourished—and led to loads and loads of data! Businesses need to build data centers to store information. Not only that, but if you...
08 JUNE, 2020 by Eric Boersma Every company needs a disaster recovery plan. This is just a simple fact of life. Your company needs to know how to recover when something breaks or you can’t get access to something you need. In larger, more advanced tech companies,...
25 May, 2020 by Daniel Longest Zombie and ghost assets sound exciting, like a late-night movie you’d watch around Halloween. While in reality they may not be that exciting, they’re scary if you don’t understand and prevent them. The good news is the steps you need to...
05 May, 2020 by Eric Boersma Taking on Site Reliability Engineering (SRE) is not an easy task. It doesn’t matter where you’re coming from. Some organizations have done a little DevOps and are trying to break into SRE. Others haven’t even taken that step, and figure...