Martyn Coupland

In this post, we look at DevOps culture further and explore the challenges of building culture in DevOps.

This is day 4/100 in the 100 Days of DevOps series.

As part of the adoption of DevOps in your company, you are highly likely to have come across challenges to your DevOps transformation. This is normal, and to a degree it is healthy to be challenged on your thinking and your ways of implementation.

However, this can become troublesome if not dealt with in an effective way. Companies that have not yet started their adoption of DevOps are feeling pressured to start that adoption due to competition.

The pursuit of this advancement can however make companies and particularly teams uncomfortable as people are pushed out of their comfort zone. Making strong progess comes with challenges, however the value you return in the end pays off.

• Rising above the Dev vs Ops mentality
• Moving from legacy to cloud native
• Excessive focus on tools
• Resistance to change
• Toolset clashes

Let’s look at these challenges in more detail.

Rising above the Dev vs Ops mentality

There is a cliché in DevOps, that I’m sure many of you will have seen at conference presentations, I know I’ve used it a few times! That is of developers throwing code over the fence to operations and their strong difference in priorities.

Developers are traditionally focused on innovation, iterating changes as quickly as possible such as new features and the resolution of any bugs. Flip that to operations and their goal is to maintain service levels. Both teams goals are in competion with each other, their goals are different.

They must align the teams’ goals and priorities. Handovers between different teams are also costly, time-consuming, and inefficient. Integrating different teams is at the root of DevOps, and it is the first hurdle that any company must overcome when implementing DevOps practises.

Moving from legacy to cloud native

Even if it has served the company for years, older infrastructure and applications can be problematic. Relying on legacy infrastructure can lead to stability issues, a lack of support, and falling behind the rapidly advancing competition. Using infrastructure-as-code in conjunction with microservices is another step toward a future of continuous innovation. It alters the development lifecycle to respond quickly to changing markets and customer needs. Whenever a company does not remain innovative, it will be quickly replaced by one that does, regardless of how popular that company has been.

Microservices, on the other hand, have a high barrier to entry. It has its own set of issues that must be addressed. When migrating from a monolithic and legacy infrastructure to a microservices architecture, you must have the foundations of automation, configuration management, and continuous delivery in place to deal with the increased operational workloads that microservices bring.

Excessive focus on tools

With the exciting prospect of implementing DevOps, the market’s flashy new tools may appear to solve every problem under the sun. However, when new tools are introduced, you must also train staff on how to use them, ensure that they meet security requirements, and, of course, ensure that the tools are well-integrated with the existing infrastructure. All of this can take your attention away from your main priority, your team.

Your team and your companies structure are critical to DevOps. Once you have the proper structure in place, the team’s processes will follow. Once the processes have been defined, the tools required to meet the processes can be determined. Make it a point to prioritise your team over your tools. When it comes to DevOps, the people on your team are the most important factor. There will be confusion if they are not trained on newly implemented processes and tools.

Resistance to change

The transition to DevOps can be frightening for the majority of team members and key stakeholders. Packaging it as an evolution of current development practises rather than a revolution may help with this problem. Telling someone they need to change can be perceived as a negative reflection on the person receiving the advice. Change in DevOps does not happen overnight, it must be smooth and gradual.

Once teams see the benefits of working together in action, other teams will naturally want to adopt the new ways of working. This will gradually reduce the feeling of unfamiliarity and get everyone on board with the new world of DevOps.

Toolset clashes

There is also the issue of Dev and Ops teams using completely different tool sets and metrics. As simple as it may appear, it is beneficial to sit down with both teams and determine where it makes sense to integrate the tools they use and unify the metrics they monitor. Some teams may be hesitant to abandon legacy tools that are not only technologically inferior, but also slow down the entire infrastructure due to compatibility issues. Ensure that the tools being implemented are aligned with the company’s goals and do not detract from the main goal: the apps being developed.

Overcoming these fundamental challenges early on will make the transition to DevOps much easier. Over time, each team member will become accustomed to the feeling of constant change and innovation. Once the Dev, Ops, and other teams learn to work together, they will figure out ways to help each other out and collaborate even more closely.

Up next

For day 5 of the series, we are looking at Agile vs DevOps.