Strategic CIO // Executive Insights & Innovation
News
1/6/2014
09:26 AM
Connect Directly
LinkedIn
Twitter
Google+
RSS
E-Mail
50%
50%

State Of DevOps: Big Gains Elusive

Can the trendy tech strategy of DevOps really bring together developers and IT operations to deliver better apps faster? Our survey shows a mixed bag of results.

Download the entire
Jan. 6, 2014, issue of InformationWeek
,
distributed in an all-digital format (registration required).

IT leaders need to stop lying to themselves. Sure, agile development and virtualized datacenters help them deliver better results. But have technology organizations really made the leaps necessary to improve IT reliability and, even more important, IT's ability to pounce when the business sees opportunity? Instead, IT organizations struggle to keep up with never-ending changes to their tech environments, especially when installing and upgrading applications. On one side, the IT operations zealots want to keep the environments as stable as possible, because  they're judged on uptime and cost. On the other side, the crazy developers want to constantly change or add apps, because they are praised for pushing new features to customers, partners, and employees.

The desire to resolve this tension explains the growing love fest for DevOps, an IT methodology that promises improved reliability and efficiency, lower costs, faster response times, and better communications among teams. Twitter, Netflix, and Facebook say they wouldn't be able to implement their tech strategies without DevOps. Eight of 10 companies in our InformationWeek DevOps Survey adopting DevOps approaches say they've realized or expect to see at least some improvement in app deployment speed and infrastructure stability as a result.

Think of DevOps as agile software development for the entire IT life cycle. Teams not only write code in short iterations, but they also test and even implement it in similar bursts, using version-control tools and more highly automated datacenter configurations. DevOps is meant to blow away the mentality of developers writing code and then throwing it over the wall to the datacenter team to figure out how to efficiently run it. In that way, DevOps has its roots in the lean manufacturing world, which fights the problem of engineers designing gear that the factories can't afford to build.

What's not to love, right? But while 75% of tech pros know about DevOps, according to our survey, only 21% of those familiar with it are using it, though another 21% say they expect their organizations to adopt DevOps principles within a year. Those organizations with no DevOps plans say other priorities take precedence, there's no demand for what Dev­Ops promises, or they lack the resources or expertise to implement it. One in five blames confusion around the DevOps concept. "The term sounds like a job role and not a process, so many manager/executive-level people don't want to hear about it," one tech pro said. One-fourth cite lack of cooperation by IT operations, developers, or both.

Other survey respondents just aren't wild about the results from DevOps. "DevOps is a mixed bag," one respondent said. "We have issues with quality control." While 31% have realized or expect significant improvement, for example, 51% say it's only "some improvement." However, that leaves a mere 3% who have seen or expect no improvement, plus 15% who think it's too soon to tell.

In concept, DevOps is hard to argue against -- who's against cooperation, speed, and stability? The goals most often cited in our survey are to deliver application updates faster with less downtime, improve IT's ability to track and respond to changes in the infrastructure, and get more visibility into network and application performance. But as the performance numbers in our survey suggest, getting blockbuster results from DevOps might be more difficult than it sounds. That's because DevOps is a methodology, not just a technical tool that IT implements. It takes significant cultural changes along with adoption of technical elements such as automated datacenter configuration.

The role of automation

The critical technical foundations of DevOps include software version control, automated configuration management of IT infrastructure, automated virtual machine deployments, and network management. Our survey finds the three most-cited tools used in DevOps are custom scripts (52%), Puppet (29%), and Chef (20%). Puppet and Chef are tools that provide automated configuration management. As an example, let's look at how an application deployment to a virtualization cluster or even a cloud provider such as GoGrid or Amazon Web Services happens now and how it looks different under DevOps.

Without DevOps, an IT operations team meets with the development team to find out how much storage it needs for a new app, which components the application uses (Apache this, Java that), which version of each component developers are using, and how the components communicate with one another. Being good engineers, the IT ops pros draw the setup in Visio, everyone reviews and agrees, and ops manually configures each system according to that agreed-upon architecture.

Too often, once the enterprise rolls out the new app, it fails because of an error that developers say they never saw in testing, and the ops pros throw up their hands, saying they followed the agreed-upon architecture exactly. The developers go back and figure out what went wrong, and once the problem is fixed, everyone is told to not touch anything. Six months later, this process happens again when developers release an updated version.

 Under DevOps, automation tools such as Puppet and Chef help alleviate this problem by requiring the developers themselves to describe the infrastructure configuration and have the tools automatically deploy the servers, set up Apache or Java with the proper versions, and configure firewall ports. As developers test the application during code iterations, they're doing so on the company's agreed-upon architecture, so when the app moves into production the process is usually much smoother.

Let's keep the big picture in mind, though. Although these tools are important, they're a means to an end -- an IT architecture that puts apps in end users' hands -- and it's the end architecture that must be defined, discussed, iterated on, designed, and then implemented within the tool. As one respondent to our survey said: "The key point to remember is DevOps is much more about culture than it is around tooling. ... Both DevOps and Agile borrow key concepts from lean manufacturing, so it's all about communication and openness."

The DevOps methodology forces the various IT teams into a more mature process that puts less trust on the individual team members to drive results and instead requires trust in repeatable and reliable processes for tasks such as virtual machine configuration.

Back to our example of server configuration: Under DevOps, IT wouldn't rely on a single engineer who "knows how it was set up before." Instead, IT uses a configuration that's documented, easily repeatable by developers running the tools in a lab, and, most important, validated by both development and IT ops. If the DevOps process works, there should be less finger-pointing, less reliance on tribal knowledge of how all the knobs and buttons must be set in the infrastructure, and more focus by team members on the end goal. That end goal is the IT architecture, and ultimately the experience that employees or customers get from the apps.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
1/6/2014 | 6:34:07 PM
The DevOps conundrum
Excellent discussion of the DevOps conundrum by Michael Davis. I agree with almost everything he said but would add the cultural change won't occur without first ruthlessly simplifying and rationalizing the enteprise infrastructure. Legacy applications are a mix of Unix, Windows, Linux and some proprietary operatings systems. Get that mix down to Linux and Windows, limit the tools and technologies that can be introduced and then you may have a shot of getting to effective DevOps. In a word, simplify the present and future architecture. Another way of saving this, move your infrastructure in the direction of sophisticated virtualization and then private cloud. This brings the enterprise closer to the environment that Facebook and Twitter employ. Even after the architects tell you how to do it, it's still hard to get there.
scriptrock
50%
50%
scriptrock,
User Rank: Apprentice
1/6/2014 | 3:36:43 PM
Hit The Nail on the Head
Michael has taken the view up one level again and focused in on the first part of the chain ....architecture - These guys are often the missing part of the conversation and given they can determine an enterprise technology standard/strategy it's great to see it being called out so clearly.  Really enjoyed this write up and will be recommending it to others.  Thanks Michael!

Check out our blog write up on this article here:  https://www.scriptrock.com/blog/state-devops-informationweek-nails/ 
TerryB
50%
50%
TerryB,
User Rank: Ninja
1/6/2014 | 2:10:04 PM
Re: Culture change required
This is an area where web and mobile store applications have changed IT. These topics used to only be the problem of major software firms who wrote o/s and ERP applications. Today you can basically consider Facebook an o/s but with the added pressure of maintaining sex appeal to consumers so they don't jump ship to the next cool thing. (Snapchat anyone?) That means frequent updates with some substance. In the old o/s and ERP days, it took a major event to jump those ships and you didn't have your customers demanding these frequent changes.

DevOps better work or people like Facebook will quickly run themselves out of business, not something SAP ever had to worry about. And still don't.

That said, it is no magic bullet that solves the politics and CYA of these big companies and their job specialization. Just makes me appreciate my career of developing inhouse applications for a known audience size and being responsible for the entire software life cycle. Makes communication so much easier. :-)
Laurianne
50%
50%
Laurianne,
User Rank: Author
1/6/2014 | 1:53:22 PM
Need for speed
The speed issue is so important. No one should be surprised DevOps is key to a company like Netflix, which is also pushing so many cloud strategy innovations. The chart here on speed of deployment tells an interesting story. Does it match with what you have found, readers?
ChrisMurphy
100%
0%
ChrisMurphy,
User Rank: Author
1/6/2014 | 12:42:19 PM
Culture change required
DevOps is a trendy idea, because it promises to address the dueling demands for greater speed AND reliability of IT systems. Are IT shops ready for the cultural change it takes, though? I wonder if some shops will go the route of trying to make DevOps a job, saying these people are in charge of making DevOps reality in the environment we have.
The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest, Nov. 10, 2014
Just 30% of respondents to our new survey say their companies are very or extremely effective at identifying critical data and analyzing it to make decisions, down from 42% in 2013. What gives?
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.