DevOps is still “rarely well completed on a large scale” after a decade of research. • The Register
interview On the 10th anniversary of its first survey, the Multi-Vendor State of Devops report concludes that DevOps is still “rarely done well on a large scale” and that “almost everyone uses the cloud, but most people use it poorly “.
The report is headstrong and there is no vendor pitch, perhaps because it’s sponsored by a variety of DevOps companies, including CircleCI, Puppet, bmc, New Relic, Snyk, and Splunk. The first survey was in 2011, so this is the eleventh report, but a decade after the first.
“We don’t want to make anything lightweight, there are a lot of crappy surveys out there that I don’t think are particularly robust in their methodology or insightful in their results,” said Puppet’s Field CTO Nigel Kersten, who told us about the State of DevOps Report From the beginning.
2,657 individual DevOps experts worldwide took part in the survey, around 75 percent of them from the USA, Canada or Europe, and covered a wide range of company sizes.
The general approach is to divide organizations into advanced, medium-sized, or underperforming companies. “Advanced” means frequent deployments, very short lead times for application changes (“less than an hour”), quick response to errors (“less than an hour”), and a change error rate of less than 5 percent. “Low” is at the other extreme, with a lead-time to change of “between a week and six months”. According to the report, “the vast majority of organizations are in the thick of it”.
This division serves as the basis for the rest of the analysis, which compares the responses of high, mid, and low performers to questions such as “Members of my team have clear roles, plans, and goals for their work.” 89 percent of high performers agree, compared to only 46 percent of low performers.
Do you have some standards!
Another striking example: 57 percent of service providers were of the opinion that their IT systems corresponded to all five essential characteristics of the US NIST (National Institute of Standards and Technology) of cloud computing, namely “self-service on demand, broad network access, resource pooling “Fast elasticity or expansion and measured service,” while only 5 percent of underperformers could check these boxes.
“Almost everyone uses the cloud, but most use it poorly,” the report said. When asked why, Kersten told us that “most people don’t use these things and have essentially moved their existing processes and practices and moved them to the cloud.”
Has the way companies do DevOps improved in 10 years? “It has definitely improved,” said Kersten; but when you read the report you get the feeling that progress is slow. In the last four years, the proportion of top performers has risen from 10% to 18%, according to the survey, and the proportion of top performers from 11% to 4%; however, most remain in the middle group (78 percent or 79 percent).
Kersten differentiates between “start-ups and tech companies” that “don’t really talk about DevOps, they just do it” and “the company, the IT mass market”, where “DevOps has become really successful at team level, but because of the Interactions between neighboring teams and departments and the weight of the processes that have sometimes built up over centuries, interaction between teams becomes critical and this is where people really fail. It’s not really a DevOps problem. “
It’s a familiar story to those who have studied software development and deployment: the methodology matters less than the interaction between people. “Well-run companies set themselves clear goals, we know which team is doing what, people communicate, they have autonomy.
The report reads more like a paper on what it takes to do DevOps (or maybe running a business) well than a typical survey, which is mostly a good thing.
Another point that emerges from the report is the importance of what it calls internal self-service platforms. “What we mean is not just centralizing IT,” said Kersten, “but moving away from the anti-pattern of many small, cross-functional teams who all do their own thing … Developers shouldn’t reinvent the wheel like I do Deploy a virtual machine or create a test environment for a CI / CD pipeline. “
Having internal platforms that do this is a good thing, he said – provided they are truly self-service. “Where we see people fail, they still use what we call ticket ops. To do this thing I have to describe what I need and then someone will give me almost what I asked for. “
One team for all functions
A cross-functional team is one that spans the entire application lifecycle from code to deployment, as opposed to a more specialized team that only deals with database administration, for example. Are Cross-Functional Teams a Good Thing?
“That depends,” said Kersten. “There are basic layers of technology that are better centralized, especially when you have regulatory burdens, but that doesn’t mean you shouldn’t have cross-functional teams … too far in either direction is definitely terrible. The biggest problem we see when there is not a culture of exchanging practices among one another. “
One thing to avoid, Kersten said, is a DevOps team. “I think we broke the term DevOps team within organizations,” he told us. “I think it’s more than useful … if you call your people DevOps engineers or cloud engineers, those kinds of imprecise titles aren’t particularly useful, and DevOps is especially broken.”
Automation is critical for fast-moving teams
What should a company do if it reads the report and finds that it is not doing well in the public cloud and not effective in DevOps? “First optimize for the team,” said Kersten.
“How much time do you spend manual labor, laborious, and focus on automating these things? Optimizing the entire system and not just every single team doing their best. We don’t act as islands within these large organizations. “
However, Kersten does highlight an area he referred to as low-hanging fruit. “We have seen that legacy environments slow down everyone’s evolutionary journey. Management’s focus on actually optimizing your legacy environments, rather than just seeing them as a sunk cost that you keep paying the bills for, is one of the most powerful things you can do. “
A section in the report on “Overcoming the burden of legacy” goes into more detail and says, “Invest in your legacy environments so they are no longer a constant stumbling block to progress.”
You can find the full report here.®