Developers and operators need to have a common monitoring and reporting mechanism against which they can work.
DevOps shops or teams tend to come together "in wartime, when things have broken really badly," said Abner Germanow, senior director for enterprise marketing at New Relic, a provider of application performance monitoring, or in peacetime, in response to an urgent business request.
"Let's say the CMO has just requested a new location-based social-enabled mobile shopping app. It's gotta happen fast, and it's gotta happen now," he said.
Those scenarios call for the creation of a "tiger team" -- experts from multiple disciplines that are tasked with quickly and iteratively building or fixing an application. That process improves dramatically with a single source of truth, i.e., a dashboard.
Dashboards help to reduce finger-pointing, Germanow said. "When you talk to people who came out of war rooms, they'll say they went in thinking that it was the server, but the data said otherwise," said Germanow. Having a dashboard also "helps move from a culture where, 'George is a jerk because he deployed that code,' to, 'the code that George deployed isn't working so let's fix it.'"
Those views don't need to be limited to IT staffers, said Alain Gaeremynck, enterprise architect at Yellow Pages Group, Canada, and a New Relic user.. They're useful for business users, too, as a way to evaluate customer experience or to identify popular features.
But on a more pragmatic level, allowing developers and operators to access the same New Relic dashboard allows Yellow Pages to troubleshoot and test against production, he said.
"No matter how good you are, you'll never be able to fully mimic production," Gaeremynck said. When Yellow Pages experiences a slowdown, developers launch a profiling session against their production systems and examine which parts of the code are taking the longest to execute.
Tying it all together
Assembling the major elements of DevOps culture -- agile, continuous integration and delivery, source code versioning, infrastructure as code, unified views -- is relatively easy in a small startup, but enterprises may have a harder time.
"With DevOps, there's a lot of talk of silos, and breaking thereof, because they're bad. And that's fine if you're in a small company with 23 people. But what if you have 23,000 people?" said Dave Zwieback, vice president of engineering at Next Big Sound, an analytics company for the music industry. Then there's the reality that most IT professionals don't have the cross-functional skills prized in DevOps environments. "Most devs don't have an understanding of the underlying infrastructure, and most admins don't code," Zwieback said.
Still, DevOps in the enterprise need not be a pipe dream, said Justin Arbuckle, chief enterprise architect at Chef and formerly chief architect at GE Capital, where he spearheaded a DevOps initiative to create consistent infrastructure builds across the organization. From that experience, he identified a few key things for enterprises to consider when thinking about DevOps.
- Start with a project that everyone can see, and that is necessary. "It is important to solve a non-trivial problem," he said.
- Follow the Agile principle of "everybody all together from early on." Assemble a cross-business, cross-functional team with operations professionals, application developers and infrastructure architects -- even auditors. If successful, those team members will become apostles of sorts, and proselytize DevOps throughout the organization, Arbuckle said.
- Include infrastructure as part of your continuous delivery process.
- Commit to elastic resources, cloud or otherwise. "You want your resources to be programmatically accessible," he said.
Organizations that follow this advice still run into challenges -- the "operational chasm" that exists between old and new ways of doing things persist, Arbuckle said. But it's a start.
About three years into a DevOps reorganization, Yellow Pages' Gaeremynck says the difficulties are worth it." At first it was painful for people, because the [old] software development lifecycle had been so much longer, and people are resistant to change," he said. But overall, "it's going really well. The overall spirit at the office is pretty good. We're involved in a lot of new projects. It's fun."
Read part one: How to adopt a successful DevOps enterprise