7 DevOps Secrets From Gartner's Data Center Conference: Experience Is Your Worst Enemy
// New Relic blog
By now, most people seem to know that DevOps represents a huge sea change for many organizations, especially large enterprises accustomed to running IT and applications more traditionally. Last week's Gartner Data Center Infrastructure & Operations Management Summit in Las Vegas, however, painted a stark picture of the difference in a number of great presentations, including ones from Rob Cummings at Nordstrom and Gartner analysts Cameron Haight, George Spafford, and Jonah Kowall.
Here are seven quick quotes that defined key takeaways from the DevOps sessions I attended:
1. "Experience is our worst enemy." The biggest issue, according to Cameron Haight, is that "enterprise IT's skills were designed for a different era's problems." The more we rely on the old things we've learned, the harder it is to improve on speed and cycle times. In fact, Rob Cummings, IT operations and DevOps expert at Nordstrom, compared the more traditional (and typical) long, slow IT projects to the Spruce Goose—the bloated, obscenely expensive wooden airplane built by Howard Hughes. Like the giant plane that made only one short flight, these projects are often obsolete before they even leave the ground.
2. "DevOps is about flow." So says George Spafford, and Cameron Haight agreed. DevOps teams have to focus on the flow of work—and that it should flow in two directions. Sure, projects go from development into production. But "done" doesn't just mean when development reaches "code-complete." Organizations also need a feedback loop back to development, said Haight. That often means that someone from development owns the pager (do they still call it that?) for a particular application—or at least is on-call for support issues. These newly blurred lines can cause difficulties in enterprise IT: Spafford's audience picked "tearing down the silos" as the biggest challenge they will likely hit in bringing DevOps to their enterprise.
3. "We're trying to develop an ownership culture." Spafford noted that people picked to be on a DevOps team should be team-oriented, focused on ownership, and self-starters. You don't want any sort of "throw-it-over-the-wall" mentality. Organizational issues can be complicated, but Nordstrom's Cummings suggested setting up the DevOps team outside the normal IT operations structure and making sure that dev and ops folks share the same managers.
Since DevOps is about continuous improvement, the team needs to operate that way as well. You needs no-blame rule, a retrospective after each release, and the organization has to be tolerant of failures. To help make these changes in his company, Cummings started with a hand-picked team, focused on people with an early adopter-style personality, and spent lots of time and effort on communicating.
4. "Beware of The Stink." Cummings warned that there's a stage of every project—right after the newness wears off—where things get really hard. He even has a name for this moment: "The stink." Every team on every project must get through it, he said, and DevOps is no exception. He offered no silver bullets, but did note that this is where having a strong leader in the DevOps team can make a big difference.
5. "They will be scared. And that's OK." According to Cummings, one of the big problems with Nordstrom's hand-picked DevOps team was a lack of clarity on exactly what they should do and how they should do it. Cummings likened them to goats looking for a hole in their fence—they were constantly searching for a way to head somewhere else, maybe somewhere more familiar. His guidance: Give DevOps teams space, but also boundaries, so they don't wander too far afield.
Another tip: Build "full stack" teams with broad knowledge. (Spafford agreed that DevOps team members need to have broad "systems thinking" to thrive.) And then let them do their thing, Cummings advised. Traditional command & control IT approaches just don't work for DevOps.
6. "Limit the blast radius." The entire company won't necessarily want to delve into the DevOps details… just the results. And while Cummings said that business folks often "get" the value of DevOps, the relationship with his line of business is "still a work in progress." He characterized it as an "ongoing discussion with executives." His next step: co-locating IT with business teams. At the same time, though, he advised that you "limit the blast radius" of any failures that might occur, especially in the beginning. Still, Spafford said DevOps can work in conservative organizations: "Yes, you can leverage DevOps in highly regulated environments."
7. "Don't wait." As uncomfortable as pushing into DevOps might seem, the alternative is worse. In fact, Cummings said pressure from Nordstrom's nearby Seattle neighbor, Amazon.com, helped pressure Nordstrom into DevOps: "Competition may be what pushes you over the edge." Spafford warned that organizations shouldn't wait for someone to arbitrarily define DevOps for them. Try stuff. Define what DevOps means to you. As Jonah Kowall put it in a final rallying cry for Web-scale IT efforts that could work just as well for DevOps: "If you do nothing else… change your culture."
- Gartner's Guidance for DevOps Success: Collaboration and Automation
- Gartner Pushes IT to Experiment—Ready Or Not
- Three Key Trends Defining the Future of DevOps
Shared via my feedly reader
Sent from my iPhone