10 Challenges to DevOps Adoption and How to Overcome Them
This blog was updated by Ruchir Sanghavi in 2021 to include 5 more challenges to DevOps adoption.
Many software and IT Ops teams have adopted DevOps practices into their work cultures to help them evolve into a faster and more innovative version of their former selves.
Companies that are yet to adopt DevOps practices feel the pressure to do so as a result of competition. Progress comes with challenges at first, but it pays off when you stay the course.
In this blog, we’re taking a look at the ten biggest challenges companies face when they seek to adopt DevOps.
1. Overcoming the dev versus ops mentality
In many organisations, we see the old cliché of developers tossing code over an imaginary wall to a centralised operations team—where developers are trying to innovate and make changes as quickly as possible, and the operations team are trying to maintain high service levels.
The objectives of these two groups often counter each other, causing friction points and resulting in handovers and increased costs, along with longer feedback loops.
DevOps is all about integrating teams together and breaking down silos within IT organisations. This journey begins by setting out a vision on how this will work for your organisation.
Understanding the roles and responsibilities of where dev stops and ops currently starts, and how these can best be integrated together, is a great starting point for any company, and it’s often the first hurdle that it needs to overcome as it adopts DevOps practices.
2. Common understanding of Continuous Delivery practices
Once you’ve identified that your code needs to be continuously delivered to minimise feedback loops, and your engineers have implemented pipelines and CI tooling that enable you to do this, you need to ask yourself this question:
Do your feature teams really understand what it means to continuously deliver your software into your environments and at a greater frequency?
Most organisations will have their own definition of what Continuous Delivery means for them. For us, we define Continuous delivery as a set of processes that allow you to reliably and sustainably release new software changes of all types (new features, bug fixes, etc.) by ensuring that your developers’ changes never break the main project—maintaining it in an always-deployable state.
The process allows you to verify that your full project is in a workable, clean state, before deploying to the production environment.
Providing a clear definition of Continuous Delivery for your organisation can help in establishing a common understanding of what it means to continuously deliver and how to achieve stability.
3. Moving from legacy infrastructure & architecture to microservices
Older infrastructure and applications with complex architecture stacks can be problematic, even if they have served the company for years.
Maintaining the status-quo can often lead to stability problems, lack of support and high operational costs—all ultimately resulting in being left behind the competition.
Using infrastructure-as-code together with a microservices architecture is a huge step towards a future of continuous innovation, which results in directly re-inventing and modernising the entire software development lifecycle and allows the business to quickly adapt to changing markets and customer needs.
Moving towards a more cloud-native ecosystem with microservices architecture can open up the floodgates to faster development and quicker innovation. In addition, it’s vital to have a solid foundation around automation, configuration management and continuous delivery practices to cope with increased operational workload that microservices bring.
4. Implementing a test automation strategy
Your organisation already knows that automated tests are really important and are a key enabler for DevOps practices including CI/CD. So what’s stopping the slow down on test automation?
It’s not just about saying what the test strategy is, but also going one step further with sample implementation of that strategy as a guiding north star for the teams.
This includes things like BDD practices and the three-amigos approach, as well as answering key questions such as:
- How do we do data management for our tests?
- Can we use open sourced shared libraries and common practices?
- What does a good end-to-end test look like for our code base?
- What should our smoke tests really do?
Having a clear understanding of how to implement the test strategy can go a long way in getting test automation adopted across the wider organisation, shortening the feedback loops and getting your products out the door quicker!
5. Too much focus on tools
With the exciting prospect of adopting DevOps, flashy new tools in the market can seem like they solve every problem under the sun.
However, with the introduction of new tools comes the need to train your staff on how to use them, ensuring they meet security requirements and are well-integrated with the existing infrastructure.
All this can divert you from your key priority: your team.
Your team and your org structure are key to DevOps. Once you have the correct structure in place, the processes of the team will follow. And once the processes are defined, then you can determine the tools required to meet the processes.
The people on your team are the most important factor when transitioning to DevOps. If they’re not trained on the newly implemented processes and tools, there will be confusion, slowing down the adoption of DevOps practices.
6. Team ownership for deployments & releases
In organisations where DevOps practices are being implemented, we still see that teams do not have full ownership of their deployment and release cycles of their software.
This is often due to lack of understanding of the difference between deploying and releasing.
Deploying is your software being installed, so to speak, into any environment, including dev, test or prod.
Releasing is then taking it one step forward, and making it available to the end-customer. This is important so that the full cross-functional team concept of “you build, you run it” can be implemented properly.
A good way to go about this is for the team to start working closely with any ops folks and taking on shared responsibility for deployments, releases and operations, so there is shared context between the two. This allows devs, for instance, to empathise with ops teams on what it takes to actually deploy & release their code in production.
Having this context can help in adopting DevOps practices for the entire team, and can enable the team to start taking ownership of not just deployments, but also releases!
7. Resistance to change
The move to DevOps can seem scary to some team members and key stakeholders. Packaging it as an evolution of current development practices rather than a revolution can help that issue.
Telling people that they need to change can be seen as a bad reflection on the person receiving the advice. It should be emphasised that a DevOps transformation doesn’t happen overnight; it must be smooth and gradual. This allows everyone to embrace the DevOps culture as they slowly become accustomed to it and realise the different ways they can contribute to the development process.
A good approach is to find a small product or full stack slice of an existing application to remodel it into DevOps practices.
Once teams can see the benefits working in action, then other teams will organically want to adopt the new ways of working. This will steadily ease the sense of unfamiliarity, and get everyone on board to enter the new world of DevOps.
8. Key metrics are being acted upon
It is hard to argue against numbers and data and many organisations have started collecting all sorts of metrics. However, sometimes organisations focus on collecting too much!
It can be easy to get pulled into a wormhole of metrics and dashboards. While these can be ventured upon with good spirits, it can quickly become a long and cumbersome process to collect basic data.
It’s important to remember why metrics are being collected: so that they can be acted upon—and that’s the key, to make improvements so that those metrics improve.
One way of doing this is by focusing on only collecting the DORA metrics and making it available for teams to consume this, with agreed (and realistic!) actions on how to improve these metrics for those particular team(s). This focused and targeted approach can enable these teams to start adopting engineering practices that can then help to deliver and embed DevOps culture into the team.
9. Dev and Ops toolset clashes
It can also be an issue when dev and ops teams have completely separate toolsets and metrics. As simple as it may seem, it is beneficial to sit both teams down and seek to understand where it makes sense to integrate the tools they use, and unify the metrics they monitor.
Some teams may be unwilling to part with legacy tools that are not only technologically inferior, but also slow down the entire infrastructure due to compatibility issues. Make sure the tools that are being implemented are aligned with the goals of the company and do not distract from your main objective.
Overcoming these basic challenges in the beginning will make the move to DevOps much smoother. Over a period of time, every team member will get used to the feeling of constant change and innovation.
Once the dev, ops and other teams learn to cooperate, they will determine ways of helping each other out, and collaborating even more closely.
10. Getting started with continuous learning
Curiosity can be a strong motivator for many to start learning! By far, one of the most important enablers for the team to start adopting a DevOps mindset is the curiosity to continuously learn, adapt and improve their skills and knowledge.
One way of achieving this is by ensuring that there is a platform that is available for teams to enable learning and sharing. This can be through communities of practices where the organisation invests in a day of learning and knowledge sharing once a month, or through lunch and learn sessions, or adopting guilds across teams.
When new technologies or products are introduced, the concept of dojos can help coaches create a classroom environment for students to learn and upskill on key changes in the organisation, with a focus on hands-on practical learning.
Similarly, a train-the-trainer model can also be implemented to ensure that practices are shared across all the teams, regardless of how big or small the organisation is. A culture of continuous learning, no matter which approach you take, can be the first small step that turns into a big leap in adopting DevOps practices.
In summary, these are all challenges we see time and again that come up within adoption of DevOps in enterprises—and there are many levers that can be pulled to ensure that new ways of working and a DevOps mindset is being adopted, whether that’s top-down or bottom-up within the organisation.
Ultimately, overcoming these DevOps challenges can ensure the organisation can retain its agility and work towards serving business value quicker to their end customers—enabling faster feedback loops.
The State of DevOps in Financial Services
We reached out to IT professionals in financial services to gain a greater understanding of innovation and DevOps in their organization. We received responses from 165 professionals, ranging from engineers to CTOs working at a range of financial services organizations from FinTech startups and investment funds to insurance firms and the biggest global banks. Check out this White Paper to find out everything you need to know about the world of DevOps in financial services.
