Puppet’s recently released 2020 State of DevOps Report surveyed and gathered DevOps perspectives from more than 2,400 IT, development, and information security professionals this year. Report themes show that organizations can scale DevOps principles and practices by providing more self-service capabilities for developers to deploy and monitor their code and modernize change management practices.
Given the complexity of today's cloud-based distributed environments, these topics are more important than ever for those struggling to reach DevOps goals of collaboration, communication, smaller releases, feedback loops, continuous learning, and improvement. The Puppet Report provides data on what’s working and some guidance on things that can help your organization.
DevOps evolution
Unfortunately, Gartner research predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations due to organizational learning and change issues. The 2020 Puppet report shows that the vast majority of firms (79%) are “mid-level” on their DevOps evolutionary scale.
We at New Relic see this with our prospects and customers as well—most companies we engage with have pockets of DevOps success but struggle to reach standardization across the company. Widespread change to a DevOps model is difficult since there is no single template for success. DevOps, like parenting, is hard because there are no hard and fast answers for the myriad situations you encounter.
The way engineering teams are organized and work together is different across organizations. A book, Team Topologies, describes four fundamental team types and three team interaction patterns. At New Relic, we’ve found teams can be project-based, dev-centered, or very siloed. What a “DevOps team” should be focused on in each of these cases is different. For example, in the siloed model, development and operations teams are two different departments and worlds, with no collaboration or direct interaction. Developers code and operations folks deploy—the responsibilities and boundaries are clear. Because of this gap, communication is a pain point, and a facilitator is needed to mediate conversations. We’ve found that shared data can serve as a bridge across departments. In the project-based model, Ops is still doing deployments but works closely with developers during the project. In this model, Ops focuses on taking care of incidents and optimization.
There is no separate operations role in the development-centric model. Developers are responsible for building, testing, and deploying applications. The whole team can focus on improving incident response, optimization, and automation.
Value of internal platforms
The Puppet State of DevOps Report finds a high correlation between high DevOps evolution and a high use of internal platforms and more self-service offerings for developers. The report cites Evan Bottcher’s definition of a digital platform: “...a foundation of self-service APIs, tools, services, knowledge, and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.” A well-architected platform provides the balance of team autonomy and standardization.
So, how does an internal digital platform differ from the operations and development silos that DevOps seeks to eliminate? The report shows a high correlation between DevOps success and treating your internal platform as a product, not a project. Typically, projects are relatively short-lived. So, you gather your best people, create a platform, and it’s done. The creators get pulled off to the next important project. This is a mistake.
As important as your code pipeline is for your company, it deserves to be treated as a product. Dedicate a team and a Product Manager to it. Create KPIs and pay attention to them. Spend time with your users—the developers who use (or avoid using) the platform. See how they use or struggle with your internal tools. Strive to remove pain points for them with the same vigor you dedicate to external customers. If your investments create happy, productive developers, it will pay for itself in innovation and retention. Pro tip: Don’t mandate the use of the platform. Use carrots, not sticks. Provide functionality that makes deployment easy.
Communicate loudly and often about new features added to the platform. For example, at New Relic, our platform team saw that developers were doing canary deploys, but it took a lot of work to make it happen. Engineering management also wanted risky releases to be canaried. The platform team made it as easy as a “Deploy Canary” button that allows developers to easily set the percentages and timing of the canary; the tool also creates a canary dashboard to watch the deployment.
Change is hard but necessary
The other thing holding organizations back from reaching DevOps nirvana? According to the Puppet Report, it boils down to change management. Can we just translate this to fear of change? Heavy-weight change management processes make development teams bundle up changes so they can do the process less often. It’s commonly understood that larger releases make it much harder to troubleshoot issues. Even ITIL has gotten the message, and now ITIL 4 focuses more on change enablement than building a change bureaucracy. At New Relic, we had a “Change Acceptance Board” that was more discouraging than empowering for developers. But it was a necessary step to get an automated tool that lets developers push their own releases.
The attitude needs to be more, “How can we trust our developers to do the right thing?” rather than “How do we prevent anything from going wrong?” And this is hard, especially in larger, older, and more regulated industries. As the report says, “Pivoting to a new way of doing things requires leadership support, organizational discipline, and a ton of collaboration and alignment across every layer of the organization.” It’s as though you have your own process monolith, much like your code monolith. The good news is that you can do it, and you can learn from other successes.
DevOps success
I’m lucky to be in a position to talk to customers and witness their evolution first-hand. This includes brewing up success with a DevOps model of continuous delivery at AB InBev and introducing a DevOps framework for more agile development and operations at renowned media brand, News UK, to leveraging agile IT to increase software delivery speed and provide enhanced services at the Centers for Medicare and Medicaid.
Yes, “Find a thing, make it better, repeat!” isn’t as sexy as big, monolithic projects. But it works.
Read the Puppet 2020 State of DevOps Report and see what you can apply to your situation.
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.
