A recent survey suggests that companies practicing DevOps deploy code 30 times more frequently than others. I'm not surprised. In the past few years, we've seen at Rackspace a surge in demand from customers who want to deploy massive amounts of code -- weekly, daily, even hourly. Most of them do it using a DevOps approach, a methodology we have embraced as a company.  

When we started offering a DevOps support service late last year, we did it with the conviction born of our own company's experience. Using DevOps at Rackspace in a typical year, we push code into production more than 2,500 times, launch about 20 new cloud products, and run more than 15,000 automated tests.

In the pre-cloud world, that would never have been possible. In fact, there wasn't much incentive to work at such speed and scale. The age of web-scale computing has compressed the timeframes for everything, including the time for an app to attract its first million users.

[Want more on DevOps and continual delivery? Read Where Agile Development Fails: IT Operations.]

It took AOL about 10 years to reach a million customers; Instagram attracted that many users in less than three months.

But what exactly is DevOps and how is it preparing us for the future of IT?

DevOps is more than a set of automation tools. While it does include technology, it is also a methodology and, to some extent, even a philosophy. Like the open-source movement or agile software development, DevOps holds certain truths to be self-evident: that shipping code faster and more error-free is inherently good; that automated testing at scale makes for a better, more secure product; that the real value of engineering talent is not the manual orchestration of administration tasks, but the insight and creativity to solve interesting, real-world problems.

There are two unfolding trends in IT that make the DevOps approach particularly useful: integration and convergence.

We can probably all agree that the era of monolithic, siloed IT is a thing of the past. These days, it's not uncommon to find a CMO with a bigger technology budget than the CIO. This is a sign of business goals becoming more tightly integrated with the technology drivers of innovation.

In the current commercial landscape, there's little patience for legacy IT systems and processes, for formal requests and capex forecasting. Companies of all sizes are adopting the lean startup approach that gets developers, operations, and business folks talking every day. By integrating departments and bridging the gap between the business-minded and the tech-savvy, these companies can run faster and leaner than ever before. DevOps is one of the tools they can use to help keep the whole machine in alignment. When done well, it can do more than automate testing and deployment; it can provide consistency and cohesion among all the disparate groups that are suddenly working together toward the promise of continual delivery.

Meanwhile, convergence is everywhere -- between technologies within the same device and between technologies in multiple locations. Just as we all now carry devices that have successfully converged telephony, messaging, and photography, the technologies on both sides of the corporate firewall are blending together. Along with the proliferation of public, private, and hybrid clouds comes the need to manage all those different locations as one set of logical systems. After all, your CEO and shareholders don't care whether your app goes down on your own network or somebody else's, so why should your management, monitoring, and testing tools care?

A DevOps approach is particularly adept at keeping up with large, distributed systems and applications. It provides a framework for holding all the moving parts together. Automated testing tools, auto-scaling processes, pre-defined, repeatable workflows -- these are the most tangible forms of a DevOps approach, and they work whether the server you're managing is downstairs or halfway across the globe.

Also, because DevOps is a cultural as well as a technical approach (just like agile development), any cloud provider already using it understands that your development cycles might be measured in hours instead of days. Hopefully, they've built the systems, tools, and support mechanisms to match that heightened sense of urgency.

Of course, adopting a DevOps approach is not without its challenges. At Rackspace, we were using elements of DevOps (such as automated testing) long before we were conscious of embracing a new paradigm. But as we developed and refined our methodologies it became clearer that the hardest work was going to be cultural, not technical. It is sometimes easier to build tools that automate or define a repeatable workflow across thousands of servers and multiple environments than it is to get operations engineers and developers to engage in the required collaboration.

Why is that?

Traditionally, IT ops and software development have been driven by different imperatives. Ops teams, above all else, have been charged with maintaining a stable environment by managing for risk. Developers, on the other hand, have worked in a constant state of flux as they build, test, and ship code in the name of new functionality. Their world of necessity tolerates a measure of instability. The challenge we faced at Rackspace as we evolved was bringing these two groups together and trying to create a set of shared values. Fortunately, we are a company with a clear set of core values, two of which easily fuel the DevOps mandate: "Results First" and "Full Disclosure and Transparency."

As development and ops teams were combined, and as collaboration was dovetailed into the product development cycle, it helped our cause that we have always encouraged transparency. It's a cornerstone of OpenStack, our culture, and our methodologies. We encourage open debate, but as a team it's the result that matters. Everyone has a voice at the table in the DevOps model -- from the ops engineer who's been burned by shoddy code to the developer who's been stymied by a lot of ops overhead -- but if we're not shipping better code and product, faster, then it's just a lot of talk. Ultimately, we ensured that developers and operations teams shared responsibility for both stability and time-to-release.

Of course, DevOps won't work well for every organization, at least not without fundamental change. For some companies, speed and agility are secondary. They're willing to sacrifice time-to-market in favor of predictability. The traditional craft of IT is very good at that. Also, organizations that have large teams of siloed developers and operations engineers will find the path to DevOps arduous. Or if the culture of IT is filled with turf wars or pockets of highly distributed and well guarded knowledge, then DevOps is not likely to succeed, at least not without the cultural change that makes cross-functional collaboration possible.

As the digital world streams forward, the tried-and-true approaches of IT have started to lag behind. The Internet, the cloud, a million users in a few months -- all these things came along to disrupt the paradigm. It seems to me that DevOps might be our best chance of keeping up with whatever comes next.

Engage with Oracle president Mark Hurd, NFL CIO Michelle McKenna-Doyle, General Motors CIO Randy Mott, Box founder Aaron Levie, UPMC CIO Dan Drawbaugh, GE Power CIO Jim Fowler, and other leaders of the Digital Business movement at the InformationWeek Conference and Elite 100 Awards Ceremony, to be held in conjunction with Interop in Las Vegas, March 31 to April 1, 2014. See the full agenda here.