We've discussed previously that DevOps is a mindset. It's all about collaboration, sharing, and communication. But it's also important to recognize that one person's mindset is not necessarily the same as everyone else's. Different people see DevOps differently. And those differences can create challenges if they're not openly addressed.
In fact, the challenges of creating a common DevOps mindset can quickly become the 800-pound gorilla in the room—the gorilla that will smash your DevOps initiative against the wall and derail your efforts to create a successful DevOps culture.
So let's take a closer look at some of the obstacles to creating a common DevOps mindset—and how to overcome them. Bear in mind that this is not an exhaustive list and some challenges may not apply to your organization. However, these are quite common in the enterprise and very likely you are facing some or all of them.
Fiefdoms: Silos of control belonging to development, operations, security and infrastructure. These are organizations of highly skilled and talented people who have learned many hard lessons over time. They've been there and done that. And they may not yield control to outsiders easily. Very likely this is a trust issue for them. Trust can be a very an emotional issue. And so trust is not given easily or quickly. This could be your toughest problem and one that has the greatest potential for disaster. Everyone needs to play nicely in the DevOps sandbox. Breaking down the fiefdom barriers is essential to success.
Variance in Vision: If you asked a room full of DevOps participants what DevOps means, each could give you a different answer. While differences of opinion are not necessarily a bad thing, widely varied opinions about the goals of DevOps and how it is to be achieved can put your initiative in serious jeopardy. DevOps is supposed to be predictable and repeatable. All the moving parts should operate in harmony with each other. Everyone should understand how they fit into the grand scheme so that each part of the process produces a predictable deliverable. If each player is confident that the other players are in alignment, you create an atmosphere for repeatability. With vision alignment, the players interact in an impactful manner because they understand where they fit in the overall process. This in turn reduces the risk of things breaking down when deliverables are passed to the next player.
Variance in Architecture/Infrastructure: The tools and environments in which software is developed, tested, and deployed can vary dramatically between groups. If multiple development teams are involved they each may have their own toolsets (e.g. IDEs, configuration management, build automation). The same is true for QA teams that use their own test automation tools. While QA uses one toolset for regression testing, operations may use another for sanity and smoke testing. Now operations has the additional burden of writing their own tests instead of simply reusing what QA has already built.
Infrastructure can vary between what development and QA use in their environments and what infrastructure uses in production environments. Production environments can even vary depending on geography or hosting organization. Security may use tools that developers and QA don't use or understand. The list can go on and on.
All these variances will introduce risk in achieving predictability and repeatability. It should come as no surprise that software that works well under one architecture/infrastructure may not work well in another. When defects are discovered by operations or (gasp!) reported by the customer, the variances add extra complexity in triage and remediation or extra investment must be put into the development and QA phase of the process to account for all these variances.
As mentioned above, you could be facing more than what's listed here. Take care to identify your challenges. Anything that can get in the way of disparate teams working well together will need to be addressed. More often than not, the underlying cause is trust and your organizational history of successes and failures.
In the next part of this blog, we will discuss things you can do and what you should address to achieve the DevOps mindset.
