The latest State of DevOps report by Puppet is in. This market analysis marks the ten-year anniversary of the report. The survey encompasses the firsthand experience of more than 2,600 professionals around the world across organizations of all sizes. New Relic, along with ten other organizations, sponsored the report with each response resulting in a donation to charitable causes such as homelessness and food scarcity. Although every effort was made to remove bias with the target population and sampling method, it is worth noting that 74% of the survey respondents were from Europe or the US/Canada, and 53% were from the Technology or Financial Services Industry.
The last ten years have seen an evolution and crystallization of the definition of DevOps. Per the report, it’s finally widely accepted as a “model of best practice for Agile development,” not just a department name. It’s truly a methodology that can be measured and discussed in a common language. And yet there is still ambiguity around what DevOps really is. According to the report, it’s not just automation, moving to the cloud, or security. We’ll dive more into all three of these DevOps topics later.
While there’s still a lot of ambiguity around DevOps, 83% of organizations surveyed have implemented DevOps practices. Over the past four years, there has been a significant increase in the number of organizations with “highly evolved” practices (from 10% to18%), but the number of firms “stuck in the middle” has remained relatively consistent and represents the bulk of organizations at 78%. That means that the bulk of organizations see the value of investing time and resources into DevOps but still don’t benefit from the full potential a highly evolved practice can bring.
Two trends also emerged as pervasive barriers across organizations regardless of where they are in their DevOps journey: legacy architectures and a shortage of skilled resources. In lieu of abandoning legacy architectures, the report recommends breaking issues into categories in order to facilitate tangible goals and action plans. Investing in legacy architectures may seem counter-intuitive, but even small steps such as virtualizing a legacy architecture can help remove barriers to progress.
The shortage of skilled resources is also identified as a significant barrier even for the most evolved organizations. A gold mine of highly skilled resources isn’t hiding behind any door just waiting to jump out, so while developing talent, we have to look at the two areas that can mitigate this shortage: automation and autonomous self-service.
DevOps and automation
Understandably, automation is pervasive in highly evolved DevOps practices. 86% of high performers agree with these two statements:
- “The automation my team uses improves the quality of our work.”
- “My team has automated most repetitive tasks.”
Mid-evolution companies also use automation widely (62%), making it clear that automation is a necessary step towards evolving a DevOps practice, though in itself it is not a guarantee of success. Ultimately, DevOps is just as much about a cultural shift as it is about using the tools of the trade. So where does culture fit into automation? It’s all about valuing what DevOps provides and embedding it into workplace culture.
For low performers, or companies that haven’t automated much, you might expect they would highly value what they have automated, but the reverse is true. Companies with low automation (25%), are not likely to incorporate more automation because barely half (51%) of respondents using automation think it improves the quality of their work.
Notice the difference between high- and mid-evolution companies versus low-evolution companies. There is a significant lack of awareness at low-evolution companies regarding how automation can benefit their teams.
We’ve all been on the receiving end of feeling like we are dealing with too many systems, forms, and confusing processes. But sometimes these hurdles, which seem like obstacles at first, can lead to positive change in the long run. When individuals don't understand the long-term benefits of DevOps, they are less likely to implement DevOps or see the value that automation can bring.
So while DevOps isn’t necessarily a culture in itself, it’s important for companies that want to use DevOps to actually value practices like automation—and work towards teaching their teams that the short-term toil to implement good processes can lead to major benefits over the long run. For companies with low-evolution DevOps practices, that means it’s important to capture and communicate the measurable value of automation not just to senior management, but also to SREs and other practitioners in the trenches.
According to the survey results, almost everyone is using the cloud, but most people are using it poorly. 65% of mid-level firms report using the cloud, yet only 20% of mid-level respondents are satisfying all five of the National Institute of Standards and Technology (NIST) cloud capability metrics.
Adopting a platform with full leadership support empowers other teams to get common building blocks and tools efficiently instead of working in isolated silos that create toil.
In order to incorporate these tools, communication is again vital. Who is responsible for overseeing and implementing these tools, how do you engage with both the tools and the teams involved in the process, and most importantly what are the dependencies? But communication alone can become a barrier with unlimited meetings and the ephemeral availability of stakeholders.
Low- and mid-evolution organizations can advance their DevOps practices by clearly documenting and communicating the effects of their processes. Doing so empowers teams to be more autonomous and to use self-serve DevOps tools.
Culture is essential, and action is needed to change the culture
Six out of ten high-evolution organizations report that DevOps is actively promoted. Nearly 18 percent of high-evolution organizations report they have no specific cultural barriers, so while these companies may have excellent DevOps practices, most do face some cultural barriers. However, these companies proactively promote DevOps anyway, doing the cross-functional work necessary to build support for their practice, creating knowledge-sharing practices, and implementing approval processes that enable fast-flow optimization.
Note the huge difference in levels of resistance in the chart below. While 86% of high-evolution organizations are either actively or passively promoting DevOps, only 35% are doing so at low-evolution organizations—and 43% of low-evolution organizations report active or passive resistance to DevOps instead. Even mid-evolution organizations report 24% resistance, which can lead to barriers in implementing DevOps practices.
Even in the most resistant, least-evolved organizations, though, the evolution of DevOps is identified as “actively resisted” only 13% of the time. Actively promoting DevOps practices and showing executives and practitioners how DevOps practices can directly benefit them can help lower passive resistance and lead to positive cultural changes over time, including the implementation of DevOps best practices.
Avoiding risk is risky business
High-evolution companies are more tolerant of risk with respondents only half as likely (15%) as low-evolution companies to say they discourage risk.
This is an interesting finding because well-implemented DevOps practices decrease risk—and yet low-evolution companies aren’t implementing those practices. For instance, automation removes the possibility of human error, yet low-evolution companies are less likely to be using automation—or appreciate the automation that is in place.
DevOps also includes the process of continuous deployment, which involves frequent, small deployments that are quicker to execute, easier to revert, and lead to a lower cognitive load. Continuous deployment helps manage risk, and yet low-evolution companies may be less likely to implement these kinds of DevOps practices.
As the report states, “the result of all this is that those organizations that claim to be discouraging risk are actually following practices that increase risk, and many of their existing practices around risk management of infrequent deployments are simply risk management theater.”
In short, DevOps can help your teams manage risk, yet the very companies that are not fully utilizing DevOps and the resulting benefits are the most risk-averse. By helping to manage risk, DevOps practices can make you more tolerant to other kinds of risk, including the creative risks that can lead to profoundly positive changes for an organization in the long run.
Platforms: A new way to think about ‘lift and shift’
One important callout about the future of DevOps is how organizations use internal platforms as a product and their prevalence in highly-evolved organizations. These internal platforms can be the foundation of collaborative communication and self-service.
According to the report, low and mid-evolution companies were 7.5 times more likely to have applied automation and platform-like practices to just infrastructure (such as VM provisioning) than developer components like rate limiting, source IP geolocation routing, and so on. Highly-evolved organizations have embraced the internal platform as a product to move beyond just infrastructure at 2x and 20x the rate of mid and low-evolution groups. Everyone is trying to “move the needle” or “lift and shift.” Making the bold move to recognize and correctly structure teams around internal platforms may represent the greatest opportunity for organizations to build more highly evolved DevOps practices.
A word on security
As a person who has had the opportunity to personally work with and advise on security practices to governments as well as leading organizations around the world, I noted that the authors of the report don’t agree on the relationship between DevOps and DevSecOps. The Puppet report acknowledges that highly-evolved DevOps practices are integrating security practices throughout the development lifecycle from the requirement phase all the way through building and testing (over 50% in all phases), while mid-evolution organizations are still looking at security in a limited capacity after the fact as part of an audit (48%) or when it results in a production issue (45%). However, the general consensus in the report seems to be “it’s important” with more debate around the name than how to successfully incorporate security.
Here is the reality. Breaches are expensive and very lucrative for bad actors such as rogue nations and modern-day “mobs” working outside the law with a significant financial incentive, technical knowledge, and compute power. They are working around the clock to take down power grids, steal identities, take credit card information, and gain political leverage. The risk is real, and as organizations become more evolved across all areas of the business, the information they are trying to protect usually becomes more valuable.
Security goes well beyond DevOps but certainly needs to be incorporated into DevOps practices. As the Puppet report acknowledges, it is often easier to get budget approval for security-centric initiatives. So regardless of the naming debate, incorporating security more deeply into DevOps practices is a must, and attaching projects to security initiatives makes those projects significantly more likely to get funded.
Looking to next year
The Puppet report has done a great job identifying minimum entry points for evolving a DevOps practice, and it clearly shows what’s working. In addition, it takes a closer look at areas of low mobility and identifying opportunities for change. At first glance, some of the takeaways are obvious: improve communication, ensure proper sponsorship, and increase automation. Ultimately, here are some of our favorite actionable takeaways:
- Communicate automation value not only to executives but to SREs.
- If done correctly, the design and execution of an internal platform can significantly accelerate a DevOps environment.
- Proper documentation not only aids communication; it also facilitates self-service.
- Sometimes investing a little in legacy technology can free up resources for greater change.
- Even in low-evolution companies, “active resistance” is low, meaning the best way to evolve your DevOps practice is to start actually doing it.
- Being risk-averse is more damaging than taking calculated risks.
- Security must be folded into DevOps practices regardless of the name.
- We can’t change or improve what we can’t measure. In addition to some of the actions above, make sure you take the survey next year.
A broader response set from DevOps professionals that represents the connected world we all live in benefits us all. It’s also more likely to provide even more tangible results that directly affect your business. As this year’s Puppet report makes abundantly clear, actions make a difference, even when the action is just ensuring representation.
Read the report to learn more about the state of DevOps.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.