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.

Architecture before automation

DevOps uses a circular methodology, whereby the output of the last iteration of the IT environment feeds the inputs of the next iteration. For example, when IT installs an application, the environment must open ports through the firewall. But say the app doesn't work because developers forgot to mention that the app needs to talk to Active Directory, and that requirement wasn't in the list of ports they wanted opened in the firewall. The iteration to fix that problem must be skewed toward spending more time in architecture and modeling of the processes and infrastructure so developers don't make that mistake again. Chef and Puppet tools provide configuration management for a variety of packaged and custom software, including operating systems, applications, and databases.

The real goal of these DevOps tools isn't to get the configuration files for these applications syntactically perfect. It's to serve the larger goals, such as keeping an e-commerce system running. Doing so requires managing the entire infrastructure that the configuration files create, and checking that the infrastructure they build matches the designed architecture.

For example, the architecture might describe how the environment should react to keep a system up when the database server fails because of a lost network connection, a failed drive, or even too many users accessing it. Yet when someone installs the configuration, the application uses the IP address of the database server instead of the virtual IP of the database cluster, so losing the primary server breaks the connection from app to database. If the configuration had matched the architecture, the failover would have occurred properly.

IT teams set up DevOps tools to respond to bad events in the infrastructure, such as outages from broken servers, but also to good events, such as increased demand for an e-commerce application. In either case, IT can automate creation of new environments -- such as spinning up duplicate virtual machines to handle overcapacity -- to immediately fix these common problems.

Of course, there's a catch: The very tools that automate the infrastructure, such as Puppet, Chef, or custom scripts, can drag down the infrastructure if they fail. One bad script could bring down your infrastructure, just as one bad patch update did before DevOps. An essential part of the IT architect's work is knowing the details of how the infrastructure's automation works in order to determine the impact an application change will have.

Not everyone is on board with DevOps. In our firm's consulting work, the arguments we hear most often against DevOps are that it dumps more responsibility onto developers, that developers should focus on coding and let the IT ops people deal with servers, and that having standard and staging servers offers enough reliability.

The doubts come from both sides: 23% of respondents adopting DevOps say developers are the ones resisting the methodology, 38% blame network/datacenter folks, and another 39% blame both. Certain IT pros also have a legitimate fear of losing their jobs: If existing engineers can't understand the architecture and all the infrastructure components, and then they write scripts to automate the DevOps processes, they won't fit in a DevOps environment. Although 59% of the respondents to our survey say they have the proper scripting expertise on their network and systems team to implement DevOps, 38% of those are just now developing the skill set.

Everyone on board: The security example

The DevOps name implies that only developers and IT operations can benefit from the methodology. Not true. We've seen how IT security, audit, and governance teams can work more effectively and respond to business change better using DevOps. Sadly, many people don't see things that way: Only 45% of tech pros adopting DevOps say they expect it to improve security; 32% see DevOps having no impact, good or bad, on security; and 7% think DevOps will make the IT operation somewhat less secure.

To sell the security team on DevOps, let them sit in on the deep technical discussions that team members must have to develop the associated architecture models. Those discussions are pure gold for spotting security risks.

For example, one large company was spinning up a DevOps-driven development project using a private-cloud provider, and it added a security engineer to the discussion. That engineer was shocked to learn that all the scripts the team planned to use for automated provisioning and network changes stored user names and passwords in the scripts and used domain-administrator-level accounts. That security flaw meant anyone who had access to the scripts could log in to the network and gain full access to all the servers and data. Was this just how DevOps had to be done? After poking around, the worried engineer learned that the company was storing domain-level accounts in all kinds of batch files, scripts, and application configuration files -- all in plain text accessible to pretty much all Active Directory users. He started a company-wide fix right away.

Let's face it, both security and operations teams generally have a "say no" culture. Getting those teams in the same room implementing the DevOps methodology will make deployments go more smoothly, because both teams can gain trust in the automated processes and tools. Working together, they can automate even complex tasks, such as separating data access by role, which also makes them easier to audit.

Nick Galbreath, former director of engineering at Etsy, a website for selling handmade crafts, says Etsy used the same configuration scripts that automate deployment of computing capacity to also assert security controls, such as requiring SSL or checking whether certain ports are open. Misconfigurations get reported automatically. Taken a step further, when a system is configured using a tool such as Puppet, the system could require an automatic vulnerability scan before putting the new apps on the production network.

You aren't Etsy or Facebook

Web companies such as Facebook, Netflix, and Etsy are big public advocates of DevOps. Etsy technical blogs are great at describing how DevOps tools can work at massive scale.

But you're not Etsy, so you can't just copy its model. You need to start at the architecture stage and model for your very different business needs, and you need to accept that the necessary cultural change will take time.

Web companies, for example, do a huge number of code changes but have very few applications -- the opposite of most enterprise IT organizations, which have a maze of legacy apps for which they try to minimize changes. For example, in a single month (January 2011), Etsy made 517 code deployments to a Web application production environment that served 1 billion page views. Compare that with the organizations represented in our survey; 96% typically move fewer than 60 application deployments into productions in an entire year. Conversely, Etsy has essentially one major application, while 23% of the organizations represented in our survey have more than 60 applications.

You probably have systems from the 1980s and software documentation that might as well say "Here Be Dragons," because no one really knows how those systems work and the mindset is just don't touch that code. Startup Web companies have the luxury of being able to set up their teams from the start for the integration of IT ops and development -- the entire IT life cycle -- to emphasize open communication, continuous development, and shared architecture knowledge.

Given these vast differences, why should traditional IT shops try to mimic the DevOps agility and automation of the Web giants? The reason is that both Web companies and traditional enterprises share a need for speed and efficiency. To those 46% of survey respondents who say they have more pressing technology or business priorities, or the 33% who see no business demand for DevOps, we say hogwash. Companies of all kinds want to give customers and employees new capabilities faster, and few companies have a culture whereby IT can respond reliably and quickly enough to business changes.

Agile development has solved only half the problem. DevOps is a powerful methodology to get all of IT to ditch broken processes and systems that slow down innovation and to spend more time on opportunities.

Michael A. Davis is CTO of CounterTack. Write to us at iwletters@ubm.com.

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

Previous
2 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 - July10, 2014
When selecting servers to support analytics, consider data center capacity, storage, and computational intensity.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join InformationWeek’s Lorna Garey and Mike Healey, president of Yeoman Technology Group, an engineering and research firm focused on maximizing technology investments, to discuss the right way to go digital.
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.