DevOps practices are adopted by many organizations to help them evolve into a faster and more innovative iteration. Knowing this, many more aim to move in this direction also but apply caution for one very simple reason: Culture change. The very nature of DevOps requires the dev teams to collaborate across other areas of the business particularly operations to tackle concerns head on. This can be difficult to many whose longstanding identities are bound up in their core roles. It not only challenges
“A phased approach to continuous delivery is not only preferable, it’s infinitely more manageable.”
On a practical level IT leaders have to reassess their business strategies to take advantage of the new work methods that DevOps brings. Particularly treat the multiple channels of input as valuable sources for solving the problem at hand. If we look at DevOps as evolution rather than devolution then that can help bring people on board in a positive way.
It would be naïve to think that disparity can only exist in culture differences between dev and ops teams, how about the toolset clashes? These two have totally different metrics and toolsets that need to be integrated where appropriate and unification of metrics monitoring.
“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”
In implementing DevOps, adding new tools to go along with the new team structure and mentality is tempting. Quite often it might seem that the latest thing is going to solve a plethora of concerns, but then that is the nature of the market. By all means shop around but make sure introducing new tools is restricted to the basics such as can you integrate them into existing infrastructure or are they security compliant? Do you have the manpower to use them and if not can you factor them into a new training schedule for bring teams up to speed? Are they fragmented? If so they can add to costs somewhat. The point is tools belong to process and that comes after setting up the correct structure for the DevOps team it is vital to stay on track particularly when starting out.
What happens to legacy infrastructures is an important consideration and challenge to DevOps because older applications can be problematic regardless of service track record. Stability can be compromised and there is often a lack of support that can mean older monolithic and legacy systems can really hold you back as you watch the competition march on. Microservices can present a move in the right direction towards faster development and swift innovation. Before you get too enthusiastic about this switch it is pertinent to know microservices comes with its own issues such as reliance on automation, configuration management and continuous delivery.
The latter CI/CD continuous integration and continuous delivery is a core pillar of successful DevOps but requires an effective pipeline to build, test and integrate but how much of this can be automated? Faster deployments equate to greater value from DevOps but the challenge here is to balance policies and standards without causing slowdowns in development? Automation does not leave much room for accommodation in this case.