We spend a lot of time and energy at Puppet Labs working to understand the impact and growth of DevOps among technology organizations across all industries and countries.

We share our learnings with the rest of the tech industry in blog posts, articles, and of course the annual DevOps survey. Our 2014 State of DevOps Report (.pdf) definitively shows that DevOps has a real impact on not just IT performance, but the performance of entire organizations.

In fact, done right, IT can be a strategic asset that can actually deliver higher profits and more business value.

One thing you’ll never see from us, though, is any of this work translating into a Puppet Labs “DevOps tool.” That’s because DevOps is not about specific tools. It’s about IT operations and software development working closely together to deliver software faster, with fewer errors. Tools enable this collaboration between people — they can’t create it.

DevOps is a cultural movement aimed at getting developers and operations teams aligned to reduce friction and deployment times, and to advance the goals of the business. While it’s hard to quantify culture, the benefits of DevOps are completely measurable: shorter software development cycles, fewer failed deployments, and fewer bug fixes all demonstrate that DevOps is simply a better way of working. Plus the people who talk to us about DevOps say it makes their working conditions and relationships much better, too.

When DevOps becomes a conversation about products instead of practices, so you can’t “be DevOps” without a specific product, it puts the entire movement at risk of being reduced to a tool choice, rather than staying on the level of changing behaviors or goals. Just as buying off-road tires for a 1970 Volkswagen Beetle won’t win you the Baja 500, buying DevOps XLS 2.0 won’t change the culture of your business to one that supports agility and continuous delivery.

Narrowing the focus of DevOps to specific technologies degrades the movement, turning it into mere product marketing. That’s unfortunate, because it’s clear that DevOps can be a major force for increasing the rate of technology change in organizations, enabling not just greater technical agility, but greater business agility.

Yet DevOps is a movement of technology people, and technology people use tools, discuss tools, try out new ones and discard old ones that no longer help them do the job. The development world has been doing this well for a long time. Yes, there are still COBOL developers out there, but in general, developers are always looking for better tools, and to drive new technology — some of which actually is better technology — out into the world.

The state of IT operations today is far different. It’s great that we have so many interesting new technologies, and that DevOps is working hard to push the state of the industry. But the reality is, we aren’t just a generation or two away from clearing out old technology in the IT operations world; we’re ages away. Adrian Cockroft and Netflix have set a great example of what companies at the true leading edge are able to do, but for most to advance along that path, we need to see a dramatic amount of change.

This change won’t happen for most companies in one generation, or even in a few. Furthermore, very few technologies will still be relevant a few generations later, which means any “DevOps product” is likely doomed to obsolescence by the time most people hear about it.

Even worse, a DevOps product, if it’s adopted too widely, has the potential to halt the development of DevOps itself by blocking experimentation and the fluid development of new ideas. You can’t evolve if you’re stuck with a specific technology or framework that’s considered the key to doing your job right. Just look at all the heavyweight, high-overhead technologies companies still rely on, that are painful and slow to install or update — and that make it nearly impossible to deliver great things to customers quickly.

When I started Puppet Labs, one of my goals was to help sysadmins create a world where the time it takes to go from “the technology works” to “people are using it in production” continuously shrinks. If we can do that, without compromising production uptime or security, businesses can experiment faster, get quicker and more frequent feedback on new products or services, and keep iterating.

Faster technology cycles aren’t just a sign of technology competence or awesomeness: They’re an engine for faster and stronger business growth.

DevOps is all about promoting collaboration between traditionally siloed teams to enable the business. So I urge you to delve into DevOps culture and practices, and to encourage the changes within your organization that will bring about faster technology change.

But you won’t get there just by buying tools. The tools enable your people: They can’t create the culture.


Luke Kanies founded Puppet and Puppet Labs in 2005 out of fear and desperation, with the goal of producing better operations tools and changing how we manage systems. He has been publishing and speaking on his work in system administration since 1997, focusing on development since 2001. His work with Puppet has been an important part of DevOps and delivering on the promise of cloud computing.