WavebreakmediaMicro - Fotolia

Get started Bring yourself up to speed with our introductory content.

Mending the DevOps culture clash

Companies need to tread lightly as they try to speed up application development.

The promise of DevOps is clear. However, the change in how companies build applications can create antipathy between the development and operations groups.

Sometimes, ops staff can view developers as sitting in their ivory towers cranking out code all day, wanting to release applications as soon as possible, oblivious to real-world system constraints. Developers can see ops as doomsayers, always claiming that the IT infrastructure will break down under the strain of any newly written code. The pace of change in business is speeding up, creating larger, more complex applications and, in some cases, heightening the tension between the two groups.

Melding the clashing mindsets is not easy. Businesses must break down the barriers between the two groups and get them working in a more cooperative manner. In addition, operations needs to put tools in place to automate the change management process. Only after those steps are taken will a DevOps culture take hold.

Focus on change management processes

Enterprises are in a constant state of flux.

"By altering business processes, products and customer service, firms are able to take advantage of new opportunities that emerge quickly and require immediate action," said Bill Claybrook, president of New River Marketing Research in Concord, Mass.

DevOps helps them meet that goal. This IT organizational culture more tightly connects development and testing with system operations. Rather than ask for new services that operations would painstakingly roll out, the two groups work more closely and automate the deployment process. The result is faster and more frequent new releases. In some cases, changes occur virtually non-stop; for example, Amazon Web Services constantly deploys software updates every 11.7 seconds.

DevOps' rapid pace puts pressure on operations and development. Companies continually design and test larger and more complex offerings. Microsoft Office 2013 Professional takes up about 700 MB of disk space and consists of billions of lines of code. Getting all of the elements in an application to work well together is a challenging process for development and operations.

Change goes beyond software

In addition to software changes, companies constantly morph as well, adding new systems, upgrading existing devices and gaining and losing employees.

"Many IT departments struggle to keep pace with system changes especially with mobile, social and cloud solutions," stated Mary Johnston Turner, research vice president, enterprise system management software at IDC.

As the volume of changes increases so does the likelihood for human error. A DevOps team may push out 1,000 changes, and one has a glitch causing problems.

Corporate myopia threatens a DevOps culture

Communication is often a primary reason for system flaws. Business units as well as development and operations collaborate in program design. These different groups own small pieces of the application puzzle, and sometimes, myopia, misunderstanding and mistrust create ripple effects. When teams tackle the same challenge from different perspectives, there's bound to be miscommunication. Problems range from wasted effort and fruitless rework to scapegoating.

The later in the development cycle a problem is caught, the more traumatic its impact will be. For instance, in pushing out an update, a developer overwrote a few shell scripts for an application running at the New York Stock Exchange.

"The system blew up, and trades could not be placed for an hour," said Bob Aiello, consultant and software engineer and co-author of Configuration Management Best Practices: Practical Methods that Work in the Real World.

The result was multimillion dollar losses.

Draconian business processes

When a system breaks down, the first call is to operations, which works to maintain system availability.  The demand of 100% availability increases as employees and the business rely more heavily on IT services. Facing potential backlash from downtime, operation techies value stability and have a reputation for resisting change because poorly executed changes often cause service failures. Fewer changes equal fewer possible failures. In addition, troubleshooting becomes more complicated when systems are in a constant state of flux.

To protect the infrastructure, IT ops sometimes puts processes in place that seem almost draconian to developers. For instance, Information Technology Infrastructure Library is a United Kingdom government-backed set of practices for IT service management designed to align IT services with the needs of businesses. The processes include items such as handling change management, but developers sometimes complain that they are cumbersome and unnecessary.

To cultivate a long-term DevOps culture, organizations must strike a balance. Operations must become more effective in dealing with change. Monitoring system changes has been time-consuming, challenging work. Recently, system automation tools, such as Puppet from Puppet Labs and Chef, allow companies to provision IT resources faster and more efficiently.

Developers need to see the positive or negative ramifications of their work on other aspects of the business. One idea is to have them wear pagers, so when things go wrong, they actually feel the disruption and urgency that the support staff feels. That empathy will make them more judicious when pushing out new releases.

DevOps tries to link operations and development more closely together. In theory, adopting a DevOps culture helps corporations meet rapidly changing business demands.

It's worth the effort. According to a Puppet Labs' survey, bringing development and operations closer together increases deployment rates and lowers change failure rates and time to recover from failures. But those benefits are only realized if the two groups become more empathetic and the firm invests in new tools to streamline resource provisioning.

About the author:
Paul Korzeniowski is a freelance writer who specializes in data center issues. He has been writing about technology for two decades, is based in Sudbury, Mass. He can be reached at paulkorzen@aol.com.

Next Steps

Successful DevOps practices from the start

Why experts call DevOps and security a perfect match

How DevOps increases development in the face of change

Two crucial elements for effective DevOps transition

This was last published in October 2015

Dig Deeper on DevOps and IT Certifications and Training

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

4 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What should developers understand about how operations work?
Cancel
We don't have DevOps teams, but we do have to work closely together. We don't really seem to have a clash of cultures going on, fortunately. Since we don't have DevOps teams, our dev team is forced to consider all operational issues - databases, performance, and other system constraints. We often ask DBA's and system engineers for advice and help as well.
Cancel
In my experience, the more bureaucratic process is set the less room is for initiatives like DevOps. Teams also tend to get very "territorial" about software and hardware in their control.
Cancel
Why when I read about DevOps do I see the same issues with the wall between dev and test, and so many other disciplines needing to come crashing down so that as peers we can collaboratively work together?
Cancel

-ADS BY GOOGLE

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

SearchCloudComputing

Close