Obstacles to DevOps Success

To gather insights on the state of the DevOps movement in 2017, we talked to 16 executives from 14 companies who are implementing DevOps in their own organization and/or providing DevOps solutions to other organizations.

Specifically, we spoke to:

Michael Schmidt, Senior Director, Automic  | Amit Ashbel, Director of Product Marketing & Cyber Security Evangelist, Checkmarx | Sacha Labourey, CEO and Founder, CloudBees | Samer Fallouh, V.P. Engineering and Andrew Turner, Senior Architect, Dialexa | Andreas Grabner, Technology Strategist, Dynatrace | Anders Wallgren, CTO, Electric Cloud | Job von der Voort, V.P. of Product, GitLab | Charles Kendrick, CTO, Isomorphic Software | Craig Lurey, CTO and Co-Founder, Keeper Security | Josh Atwell, Developer Advocate, NetApp SolidFire | Joan Wrabetz, CTO, Quali | Joe Alfaro, V.P. of Engineering, Sauce Labs | Nikhil Kaul, Product Marketing Manager Testing and Harsh Upreti, Product Marketing Manager API, SmartBear Software  | Andi Mann, Chief Technology Advocate, Splunk

When we asked "What are the obstacles to the success of DevOps initiatives at a company?", here's what they told us:

• Urgency and the desire to go backwards rather than forward in DevOps implementation. People in power can be slow to change because there are specific ways to organize into teams, units, and kingdoms. Some kingdoms may go away and this results in power battles.
• People in management are too comfortable in their current jobs and don’t want to change. They’re either blocking change or moving to another company that’s not embracing DevOps. There’s fear of having greater responsibility for the code running in production. However, this gives the engineering team a lot of freedom to try new things, deploy as you wish with almost instant gratification by seeing the impact your code has on end users. Design, develop, test, and run with a feedback loop to see how people use what you produce. Get over the responsibility hurdle by focusing on quality early in the development process and gaining confidence in what you’re sending to production.
• The initial pain of change. Developers like structure. Bring people to do the work and the discipline to implement.
• Culture is still a big issue, especially in companies with ingrained siloes. There is no “one size fits all” solutions. There are multiple model methodologies and applications. Multiple modes of software delivery. Automate a process focusing on what you understand – business process reengineering.
• Silos and walls. Everything is mental – the not built here mentality, especially with start-ups. Remove this mentality to focus on where your company adds value. Don’t worry about your kingdom. Worry about fulfilling the needs of your customers.
• The main issues are usually political. Development and operations are often under different managers, and each manager wants to preserve ownership over their area and perhaps build their team. When development is asked to do things on behalf of operations (or vice versa), there can be requirements to formally track time or costs that get in the way of the fluidity that is the hallmark of properly implemented DevOps.
• People and organizations concerned with losing control and visibility. This is especially challenging for senior executives. There’s not a loss of control or visibility if you’re doing it right. We’re promoting collaboration among people who are traditionally introverts with a common data fabric facilitating the discussion of deliverables. Build relationships internally so people talk to each other to make decisions on endpoints that results in better code.
• Getting customer feedback quickly.
• If the hosting provider changes it will impact your automation scripts. They will need to be updated for the new hosting provider. There’s an abstraction of hosting providers. Reducing the risk of deployment implementation. We use Vagrant so we can start building systems directly on the computer and move to Linux. It makes the development environment very like the production environment, when have microservices it takes time to reboot on a local machine. Docker containers allow you to develop on your machine, run in production, build up faster with stackable containers enabling you to build and manage piece by piece.
• 1) Depends on the client. Bigger enterprises process changes and cultural issues. 2) Smaller companies adopt DevOps quickly but can be costly to implement software implementation. 3) A behavioral challenge since people want to do what they’re familiar doing. Reduce the gap between development, operating, and testing. 4) A process of standardization will ensure that everyone else is using API standards and specs with an open API environment. 5) Fragmentation of the market devices, operating systems, and ecosystems is more difficult. User flows enable you to see what they’re using to access the data. 6) Hardware is working to ensure software app performance. You can see the way people are testing is changing (Agile Testing Pyramid). More API and fewer GUI test cases.
• Three main issues: 1) The delivery process opens multiple siloed departments – development, operations, infrastructure, and security. Each hand off slows down the process because each channel has a different working mode, with different incentives and KPIs. Ultimately this slow the feedback loop. 2) Multiple different technology stacks cannot easily translate into production. 3) Infrastructure and application management are separated by siloed departments and the feedback loops are not working well.
• Security slowing down the process by taking too long to analyze code or returning a lot of false positives that must be addressed. Anything that slows down the process and causes the DevOps team to lose confidence is disconcerting. Tweak the format of code used by the organization to minimize false positives.
• Organizations that are just starting out have a tendency to “boil the ocean.” This is a process for incremental improvement. The Puppet research shows that over time companies see fewer incidents. It may be painful getting started but once you get past the initial start-up, the tools and the automation reduces the number of incidents, and thus the amount of pain felt by the organization.
• Change in the way of thinking how infrastructure operations should involve anyone within the organization in the process for conversational development throughout the organization.

What are some obstacles to the success of DevOps initiatives you've seen?