How to implement a solid DevOps team structure
DevOps collaboration can wipe development and operations teams of hostility and negativity. Dashboards and tiger teams turn wartime to peacetime.
Developers and operators need to have a common monitoring and reporting mechanism against which they can work.
DevOps shops, or DevOps teams within a more traditional organization, tend to come together in wartime, when things have broken badly, said Abner Germanow, former 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 who are tasked to quickly and iteratively build or fix an application. That DevOps approach improves dramatically with a single source of truth, i.e., a Dashboard.
Share the same DevOps approach
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 [the problem] was the server, but the data said otherwise," he said. 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, former enterprise architect at Yellow Pages Group in 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 as a functional team enabled 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 experienced a slowdown, developers launched a profiling session against their production systems and examined which parts of the code were taking the longest to execute.
DevOps practices in enterprise IT
Assembling the major elements of DevOps culture is relatively easy in a small startup, but enterprises might have a harder time.
DevOps practices vary but generally include:
- Agile
- CI/CD
- source code versioning
- infrastructure as code
- unified views
"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, former 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 a DevOps team structure. "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, former 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 nontrivial 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 CD process.
- Commit to elastic resources, cloud or otherwise. "You want your resources to be programmatically accessible," he said.
Organizations that follow this advice to adopt DevOps practices still run into challenges -- the operational chasm that exists between old and new ways of doing things persists, Arbuckle said. But it's a start.
About three years into a DevOps reorganization, Gaeremynck said the difficulties were 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."
