For Modern Business, it’s ‘DevOps or Die’
If your company is in the software business, or if software is part of your competitive edge in any way, then failing to adopt a continuous integration and deployment (CI/CD) pipeline will spell the end of your organization.
“DevOps is the new normal. If you are a large company today, you are a software company, whether you want to be or not,” said Luke Kanies, CEO of IT optimization software provider Puppet, speaking at the OpenStack Silicon Valley 2016 conference, which took place this week in Mountain View, California. “And if you are a software company, you need to figure out how to optimize the entire end-to-end software production.”
Kanies’ dire warning may not come as good news to many company executives, who view, probably rightfully, that the costs and cultural adjustments needed to come with adapting to DevOps is steep, perhaps too steep for some to take on. This is unfortunate, because failure will result in their demise, Kanies predicted.
Over the past five years, Puppet has surveyed 25,000 people in the IT field, about DevOps. It has found that DevOps has been instrumental in the success of many companies.
The results of Puppet’s survey are quite surprising, even if you are already drinking the DevOps Kool-Aid. The top performers in the survey deployed changes in their production code more than 200 times than the average. When there is a fix or an improvement to to be made, they respond 2,500 times as quickly.
“The time between idea and production, between discovering a problem and the customer experiences the benefit of solving that problem, that time is 2,500 times shorter for the top performing organizations,” Kanies said.
(The survey, though exhaustive, does have some limitations. Since Puppet defined the top performing organizations by the variables they set, their report does not find a direct cause-and-effect relationship between DevOps principles and company performance. Study authors will be publishing a statistically rigorous analysis in a soon-to-be released an academic paper.)
Because they are making challenges so much more frequently, these companies experience a third fewer failures than the average organization. And when they do experience a failure. And when they do experience a failure, they can fix the problem 24 times faster.
From Puppet’s “2016 State of DevOps Report.”
Since it is a five-year survey, Puppet has found that the disparity between top performing organizations and average organizations is growing. In other words, the costs for businesses not moving into DevOps, especially those with DevOps-savvy competitors, is growing.
The survey has pointed out to Puppet is that the only way to become a “great software company” is to “optimizing the end-to-end software production,” Luke Kanies.
“As a result, success in the next decade means figuring out how to do that optimization, how to move from being a great company to being a great software company,” Kanies said. “You have to commit. You have to find a way to get from the old style of building software to adopting the new world of DevOps practices.”
Stupid but Important, or Smart but Irrelevant?
Of course, a company may have many good reasons for not adopting DevOps. Although readers of this site may be familiar with the new microservices and container-based agile architectures, the truth is an overwhelming percentage of organizations are still running what would be considered legacy software (otherwise known as “production software”). Many are still stuck between running their apps in virtual machines and running in a traditional client-server architectures.
“You can’t afford to ignore that reality,” Kanies said.
But even small changes to the processes and tools can bring considerable benefits. Look for areas of automation. Also, a small change may bring about a new way of thinking about the entire pipeline, which can lead to big advances in efficiency, Kanies said.
Top performing teams deploy 200x more often & recover from failure 24x times @puppetmasterd #OSSV16 #DevOps pic.twitter.com/AzD3byiFAN
— The New Stack (@thenewstack) August 10, 2016
The initial benefits of DevOps come from time reclamation.”It’s all about finding ways to get time back in your day,” Kanies said. It is about automating the small tasks, as well as minimizing interruptions.
“Many people have no time to spend hours on a single hard problem. They get interrupted constantly,” Kanies said. “If that is your problem you need to find a way to get the interruptions out of your day. Once you have that, you can take that extra capacity and do more interesting, strategic processes.”
One of the industries feeling the brunt of the DevOps upheaval is the infrastructure software industry itself, the implications of which were discussed in another OpenStack Silicon Valley session with Battery Ventures‘ Technology Fellow Adrian Cockcroft and Mirantis Chief Marketing Officer Boris Renski.
In June, Renski wrote a blog post “Infrastructure Software is Dead,” which discussed how the world of infrastructure software is changing away from the traditional deployment models, as exemplified the traditional enterprise software vendors, such as Oracle and VMware, that package software and release it in periodic intervals.
The delivery model for enterprise on-prem software has changed radically @zer0tweets w @adrianco #OSSV16 pic.twitter.com/BBchO8AeDo
— The New Stack (@thenewstack) August 10, 2016
Mirantis, when it started shipping its OpenStack distribution, started with this prepackaged format as well, by shipping out periodic upgrades of the entire stack. But it didn’t really fit with how its customers were running their private cloud operations, which increasingly involve continuous upgrades coming through come through the customer’s CI/CD pipeline of staging, testing then deploying into production.
“It’s a different delivery model for software. You are actually continuously consuming code” Renski said.
For enterprise infrastructure software, “The purchasing cycle has collapsed and the deployment cycle has collapsed,” Cockcroft agreed. The old ways of upgrading enterprise software, such as an SAP system, was by having a dedicated team come in and spend months doing the upgrade, and then moving on to the next project. This approach was centered around the model of large periodic updates of the software, which may come out about ever 18 – 24 months. But the move to CI/CD means the updates come in smaller chunks, and arrive more frequently.
“The developer community has basically learned how to do microservices, break everything into small pieces that they can deploy independently. So you end up with a situation where there really isn’t a version of something,” Cockcroft said.
TNS Research Analyst Lawrence Hecht contributed to this article.
Feature image: Stevens Creek Trail, Mountain View, California.
