7 Habits Of Successful DevOps

DevOps is a worthy endeavor, producing a deeper understanding between the development staff and IT operations. Then again, maybe it's just a shell game being played by those charlatans down the hall.

Those seem to be the two poles of misunderstanding about DevOps, Forrester Research analysts Glenn O'Donnell and Kurt Bittner suggest. They published a report Tuesday, "The Seven Habits Of Highly Effective DevOps."

The report at first sounds like the famous line from Cool Hand Luke, "What we have here is a failure to communicate." O'Donnell and Bittner point out that an IT leader who wishes to implement DevOps must clear up a lot of misunderstanding. In the past, what the development team produced didn't always run well in operations, and the feedback offered by the operations staff was viewed as hypercritical by the developers. "The detritus of accumulated and reinforced stereotypes is destructive to organizational harmony," the authors warn in a section called, "Negative Stereotypes Cripple Your Business."

Wait a minute. The introduction of DevOps isn't the first rodeo for legions of IT employees. They have a rich amount of experience on which they base their view of the inadequacies of the other side. This feud has been going on longer than AMC's The Walking Dead.

[ Can Agile close the gap between speed and stability? See Where Agile Development Fails: IT Operations. ]

But the seven habits are not just about better public relations. The authors skillfully summarize how each side, in its isolation, sees the other.

Developers view operations as wedded to their obsolete systems and unable to adapt to developers' demands. They're basically bureaucrats who like to say "no" rather than change. Their incompetence then leads to the failure of the developer team's latest application code, hurting the team's credibility. The application didn't run well because operations "is not creative enough to understand the complex artistry of apps." (I was starting to chuckle at this point.) Operations is constantly "cobbling things together -- it's not engineering." Developers would do much better if they could circumvent ops and go out into the cloud.

I found myself laughing at the end. The characterization of how ops sees the development team was in the same vein.

Developers want to believe anything is possible and have no reality check on what it costs IT to give in to their demands. They like to "play with the latest 'toys.'" The teams "deliver lousy code that negatively affects ops' credibility." Their test environments don't test for what they should -- the ability of the app to sustain itself in production. The developers are "careless, lack discipline ... a bunch of hackers, not real professionals." Operations has to perform heroics day after day to keep their code running. It could do much better by circumventing development and just use packaged software and SaaS.

The two characterizations are stereotypes. Is it any wonder there is a gap, sometimes resembling the Grand Canyon, in communications between the groups? How then do you knit them together into a joint DevOps organization? How do you get development to produce code that works the way operations thinks it should? And how you get operations to help the development team produce the code that's needed, without attacking its "careless" ways?

Not surprisingly, the seven habits of successful DevOps start with getting the two sides to talk to each other. It's a cliché, but talking face to face breaks down stereotypes and allows each side to see the other's daily difficulties and struggles. This is not too deep an insight, but it remains a necessary first step.

"Take an outside-in approach to everything," the authors advise as habit number two. Traditional IT thinking is inside out: "Here's what IT has the resources to do and what we've done with them. Use it to the best of your ability." Instead, have both sides focus on the business customer and what should be done to satisfy his needs. That new application had 10 hours of downtime last week? That's not good for the customer. What do we need to do to produce more stability in production code?Habit number three is automating the build, test and release processes so they contain less human error. For testing to work, it must include scalability testing on the systems with which the application will run, as well as business function tests, the thing that traditional development teams excel at. Puppet and Chef now capture and help automate configurations and deployments; use them. (The authors didn't specifically mention Puppet and Chef).

The whole data center infrastructure must be revamped toward delivery of services from a more standardized environment. The process will be a long one, with both business users and developers losing some of their preferred, best-of-breed systems in favor of good enough Linux and Windows systems. The old way led to ever-increasing complexity, and that complexity was accompanied by an increasing fragility. So habit number four is simplify, standardize the development and production environment. Rigorously enforce that simplification on new applications. Then as much as you can, simplify legacy applications. It's a huge task.

Number five is to instill a culture of systems engineering across both development and operations. "Real engineering works in a disciplined, thoughtful way ... to reduce solutions to be -- as Albert Einstein recommended -- as simple as possible but no simpler." Building up software based on simple modules makes it easier to deploy and maintain, and to reuse.

Number six, the authors said, is implement feedback and feed-forward loops. Software is complex and requires feedback on how it's operating. Oftentimes, developers don't know. Testers and operators are often engaged only at the end of a project. They need to be involved early. Likewise, information that explains how an application is expected to operate, such as its dependency mapping, needs to be fed forward to operations and development teams that may be working on the next similar application.

The last habit is put developers on the frontline of support. They don't want to be there. It takes them away from the creative process of building more code, the place where their reputations are already staked out. But the developers who built the code will have the greatest understanding of why it's running poorly in production and produce the quickest fixes. And needless to say, developers will learn a lot about production as they watch their code run in its target environment.

These seven habits will not come as any surprise to the people who have already struggled with DevOps and moved their organizations closer to a combined-function IT staff. But they will come as education to more traditional staffs that are comfortable in their isolation from each other. That isolation includes some protection from being taken out of one's comfort zone and put in a situation where something more is expected of you.

Facebook automated the configuration and deployment of software to 17,000 servers using one Chef server, point out the authors. That's because it was able to build from scratch a simplified and standardized environment. The DevOps gain in automation is self-evident.

Amazon is constantly updating its production systems without fear of unintentionally torpedoing its operation. It does so through an automated test procedure in an environment that matches the production environment. Jon Jenkins, Amazon's director of platform analysis, stated at the Velocity conference in 2011 that someone is deploying code to production "every 11.6 seconds," usually to 10,000 servers at a time. In the average IT shop, such deployments would be suicidal, considering most outages are due to software updates. The DevOps gain in production reliability is self-evident.

Etsy deploys new features to its online, artisan marketplace with only one IT person on duty, thanks to its DevOps rigor of developing new code. Each addition is carefully tested and pushed when ready, rather than planning for a big team push to update a system once or twice a year.

The point of DevOps is to get both teams to treat their responsibilities as a science and to reduce the amount of science fiction involved when dealing with one another.

Learn more about DevOps by attending the Interop conference track on the Business of IT in New York from Sept. 30 to Oct. 4.