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 which haven’t yet adopted DevOps feel the pressure to do so as a result of competition. Pursuing advancement can be uncomfortable because it calls for teams to move out of their comfort zones. Progress comes with challenges at first, but pays off when you stay the course. Let’s look at a few challenges that companies face when they seek to adopt DevOps:
1. Overcoming the Dev vs. Ops mentality
The DevOps practice is all about integrating teams together and breaking down silos within IT organisations. There is the old DevOps cliché of developers tossing code over an imaginary wall to operations and difference in priorities. Devs trying to innovate and make changes as quickly as possible and operations trying to maintain 100% service levels. The truth is the goals of both teams seem to often counter each other. They need to align the goals and priorities of the teams. Also handovers between different teams are costly, expensive and a source of delay. Integrating different teams is at the heart of DevOps, and is the first hurdle that any company needs to overcome as it adopts DevOps practices.
Further to this integration, some organisations are now moving to a cross functional and product aligned teams rather than managing projects. A broad cross functional team aligns to products, by owning its roadmap, architecture, design, development, run and support requirements. This brings testers and representatives of the business into the development team and a collaborative process. This sounds easy, but for enterprises this is exceedingly difficult, often involving staff restructure, breaking up shared services and reporting lines. With this there is often a political battle about which org unit pays for and therefore is the owner of the product.
2. Moving from legacy infrastructure to microservices
Older infrastructure and applications can be problematic, even if it has served the company for years. Remaining on legacy infrastructure can spell stability problems, lack of support and the fact that you will be left behind the swiftly advancing competition. Using Infrastructure-as-code together with microservices is yet another step towards a future of continuous innovation. It modifies the development lifecycle to quickly adapt to changing markets and customer needs. If a company does not stay innovative, it will be replaced quickly by one that offers something more, no matter how popular that company has been. Replacing or modifying older, monolithic apps with newer microservices architecture can open up the floodgates to faster development and quicker innovation.
However, there is a high barrier to entry with microservices. It has its own set of problems than need to be managed. By moving to microservices architecture from a monolith and legacy infrastructure, you need to have the foundations of automation, configuration management and continuous delivery in place to be able to cope with the increased operational workloads that microservices bring.
3. Too much focus on tools
With the exciting prospect of adopting DevOps, the flashy new tools in the market can seem like they solve every problem under the sun. However, with the introduction of new tools, you also need to train staff to use them, ensure they meet security requirements, and of course, make sure that the tools are well-integrated with the existing infrastructure. All this can divert you from your key priority – your team. Your team and your org structure and key to DevOps, once you have the correct structure in place the processes of the team will follow. Once the processes are defined then you can determine the tools required to meet the processes. Make sure you focus on your team more than your tools. The people on your team are the most important factor when transitioning to DevOps. If they’re not trained on newly implemented processes and tools, then there will be confusion.
4. Resistance to change
The move to DevOps can seem scary to a majority of 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. DevOps change doesn’t happen overnight; it must be smooth and gradual. This will allow 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. It is better 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.
5. Dev and Ops toolset clashes
There also exists the problem of Dev and Ops teams having 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 that 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 the main objective: the apps being developed.
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.
The discomfort of change is better than staying behind the competition and not being innovative.
