Much is made of the archetypal relationship between DevOps and NetOps. We are constantly barraged with a litany of “us versus them” rhetoric that pits the one against the other, lobbing applications and accusations back and forth over the wall that separates them. With increased pressure to deliver apps faster and more frequently, this wall can become the digital divide that separates the winners in the app economy from everyone else.
Fortunately, this digital divide is shrinking thanks to IT automation and orchestration. We discovered a desire to collaborate on closing this digital chasm by NetOps and DevOps alike when we separately surveyed each group, digging into their use of technology, perceptions of each other, and the applications they deliver. That’s increasingly good news for businesses embarking on digital transformation efforts that require the scale and speed only automation and orchestration can effectively achieve. It’s also good news for organizations struggling with multi-cloud environments that require greater attention from already overwhelmed staff. Relieving the pressure on-premises with automation can free up resources to attend to cloud-related projects.
884 NetOps and DevOps professionals responded to online surveys conducted in the summer of 2017. We asked several perception-related questions regarding applications in general and their counterparts in either NetOps or DevOps, as well as questions focused on perception of frequency and success rates of deployments.
The results show that though the wall between them still stands, it is not nearly as high or as opaque as dialogue within communities or other industry reports purports. We found a great deal of common ground across organizations of all sizes and industries with respect to the importance of and desire for automation of the production pipeline, as well as joint confidence in the security, performance, and reliability of the applications both groups endeavor to develop and deploy.
Automation appears to be a unifying force for NetOps and DevOps. In principle, at least, if not in the specific implementation details.
While DevOps and NetOps remain at odds regarding how much pipeline access should be available via self-service and automation, for the most part both groups view the other as on the right track. 82% of DevOps and 76% of NetOps agree that each other prioritizes “the right things.” Clearly, there is common ground across the digital divide in at least goals and focus, if not always in the organizational chart.
Among dissenters on the NetOps side, the most common response as to what DevOps doesn’t prioritize enough included security. Reliability also cropped up frequently as a source of frustration with DevOps from their NetOps counterparts.
Reliability and security are as important as speed of delivery. Security is still an after thought. Performance, security, reliability.
Unsurprisingly, one of the more common refrains from DevOps regarding prioritization by NetOps centered on automation. Or rather, a lack thereof.
automation automation automation. I would like to see them prioritize automated, cloud agnostic, resource creation in the cloud space. Automation, devops, cloud, security.
This difference of opinion is likely at the root of our next key finding which exposed the effect developers and DevOps’ lack of production pipeline access via automation and self-service has on the adoption of cloud and solutions outside IT.
They can hear you now. It has long been believed that one of the drivers of cloud adoption – by business and DevOps stakeholders alike – is the lack of self-service access to the production deployment pipeline that results in lengthy deployment cycles. The not so good news is our survey validates this belief, with 27% of DevOps indicating it influences their decision to reach for cloud-based solutions “a lot” and 38% influenced “some.” The good news is that NetOps aren’t oblivious to the impact. Over 65% of NetOps say their desire to automate and provide self-service access to the production pipeline is influenced “some” or “a lot” by DevOps’ decisions to embrace the cloud.
The Blame Game is over. Contrary to popular storylines that pit NetOps and DevOps against each other in an endless finger-pointing game in the wake of incidents, we found evidence that each group views the other in a far more positive light.
The reach for cloud by those frustrated by a lack of pipeline access contributes heavily to the rise of multi-cloud and its associated challenges with security and performance, as often noted by those struggling with the resulting “rogue IT” it creates. Even as NetOps continues to engage in its efforts to offer access via automation/self-service with private cloud or cloud-like systems, there remains a significant existing investment in off-premises cloud solutions that is unlikely to be ignored. This leaves organizations with multiple cloud solutions – and environments – to manage, monitor, and secure, increasing the complexity of operating in the digital economy.
The question now is not “do we provide self-service access to the production pipeline?” but rather “how much do we expose?”
How much is enough? The right amount of pipeline access to developers and DevOps via automation/self-service capabilities brought out some striking differences in opinions. DevOps definitely wants more access to the production pipeline than NetOps is comfortable with offering them.
While we did not ask for insight into NetOps’ reluctance to provide DevOps with greater pipeline access, an answer might be found in the skills available to do so. NetOps respondents generally believe there is a gap between skills they need to do their jobs and training/knowledge they have now.
In fact, both NetOps and DevOps who self-identify as “developers” were more likely to believe their jobs would be relevant in five years given similar responsibilities and skill sets. Least confident were those identifying as Network Operators – on both sides of the wall.
The current state of production pipeline automation on the NetOps side seems to reflect the impact of that skills gap. It was not a surprise to find it lags considerably behind that of the DevOps delivery pipeline. While 11% of NetOps admit no automation of the production pipeline, only 5% of DevOps said the same about the application delivery pipeline.
The state of pipeline automation is important to note given our finding of a positive correlation between pipeline automation and frequency of successful deployments. 86% of NetOps indicating a higher percentage of pipeline automation (75% or greater) also reported greater frequency of very successful (90% or more) deployments.
But it’s not the only factor, as frequency of application changes also appears to have an impact on the frequency of successful deployments.
We’re good, thanks. Perhaps the greatest cultural divide still lies within the realm of deployment frequency. While some of DevOps delivers apps to production at breakneck speed (12% deliver changes to production more than once a day), NetOps appears to be far more comfortable deploying those changes at a slower but steadier pace.
Overall, there seems to be some measure of consensus around monthly and weekly frequencies for a plurality of respondents. Unsurprisingly, DevOps prefers to deliver more often than NetOps. To wit, of the 26% of DevOps who want to deliver more frequently, 28% deliver once a week, and 26% already deliver more than once per day.
Perceptions on the adequacy of the speed with which changes are delivered varies from group to group. It is noteworthy, however, that the majority of both (70% of DevOps and 74% of NetOps) described the frequency of changes as “good enough for us.”
That’s where the commonality ends. While a mere 4% of DevOps claimed their current schedule was “too frequent,” those on the NetOps side who described delivery frequency as “too frequent” doubled. More than one in four (26%) of DevOps want to go faster, while less than 1 in 5 (18%) of NetOps want to pick up the pace.
Ignoring desire and examining results, however, reveals what may be “the ideal” deployment frequency for balancing speed and success rates. Of the 65% NetOps and 57% DevOps who experience successful deployments greater than 90% of the time, changes are pushed into production “once a week.”
The digital divide applications must traverse to get from delivered to deployed still exists. Significant portions of the deployment pipeline remain manually driven, which will continue to drive applications to the cloud. In turn, DevOps decisions to turn to cloud will see NetOps providing more of the self-service access necessary to speed up the journey.
Automation is the key to bridging that digital divide as it enables NetOps and DevOps to work smarter, not harder, and scale operations to meet the needs of business together.
Data for this report was compiled from two, separate online surveys conducted in July 2017. Both were designed to investigate the use of automation in the application lifecycle from development to deployment, as well as perceptions of the two primary groups involved. Respondents in both groups were incentivized to participate.
Included below are additional, select responses to survey questions, sourced from both NetOps and DevOps respondents. While not a comprehensive list, they are presented here as a sampling of the type of feedback received. Product names have been edited for accuracy; otherwise, the intent is publish comments unedited and as received.
If you answered “No” to "Does your Dev team prioritize things properly?" – What would you like to see them prioritize differently?
- Stability, Quality, and Vision. Too often folks sprint towards a date and quality is the main thing that suffers. Also, not looking beyond the current task leads to a ton of rework and less-than-optimal solutions in the end (junk gets cobbled together and may work, but it's not optimal or ideal in any way).
- We need more collaboration between dev and sysadmin teams. We aren't moving away from manual administration quickly enough.
- I would like to see development teams care more about operational reliability, architecture consistency and cooperation between different dev teams
- App developers aren't thinking about network or security, security is only marginally aware of development, networking learns of the operational changes once development is done.
In an ideal world, how would you improve the interaction, communication, collaboration, etc. between your Dev and Ops teams?
- Improve metrics, monitoring, and visibility so both sides are apprised of performance. Automate the pipeline to speed delivery of services. Provision adequate capacity to avoid long delivery times.
- Replace them with smarter people
- Quit seeing each other as roadblocks and let all teams contribute where they can best add value. Automation is great, but without some oversight solutions get implemented that may work, but there is often a better and more optimal way it could have been done.
- More blurring of the line between the dev and ops teams. Should be considered "one team" with a shared goal to deliver applications in a way that can scale and perform well on the available infrastructure with minimal overhead.
- Communication doesn't matter if you're talking to the mental equivalent of rock in a tie.
- To involve the F5 team earlier in there process in the DEV cycle.
- Bring in Ops earlier in the dev cycle
- Shared code and visibility of pipelines. The more tools that can be managed by code the better (e.g. we can't reasonably manage an F5 BIG-IP in code, and that's a weak point in our process).
If you answered “No” to "Does your Ops team prioritize things properly?" – What would you like to see them prioritize differently?
- I would like to see them prioritize automated, cloud agnostic, resource creation in the cloud space. Push button infrastructure, which is definitely attainable and useful for the developers, QA, and operations.
- They need to adapt to automating everything they touch and quit fearing job loss
- Too much manual work, no automation, lack of understanding of the core technical problem. Empower the developers.
- They tend to solve problems by throwing money at them. More (expensive) equipment. More headcount to turn the crank, rather than automation.
In an ideal world, how would you improve the interaction, communication, collaboration, etc. between your Dev and Ops teams?
- I would like the Ops team to provide more tooling to abstract away the details of the operational environment
- I am developer and we need to deploy and automate the infrastructure. The ops guys need to learn to automate and some tools.
- Change the operations team to be more of an infrastructure support that automates the management of the infrastructure. This would allow the developers to use the infrastructure as more of a service instead of relying on operations to perform upgrades, server management, etc. I'd also embed operation team members into other groups as a liaison in order to help facilitate making applications easier to manage.
- Ops team needs expanded and directly involved in development and testing. less a place to go to for requests and more of an integrated partner on the front lines.