Atlanta DevOps Days Recap: Next Up NYC, Vancouver & Portland

We have been participating in the devopsdays events by presenting an ignite talk on how DevOps need to be aligned with how applications are constructed today - with open source components. The ignite presentation style is really interesting - you have 5 minutes to present 20 slides that advance automatically every 15 seconds. I started with a tightrope analogy and compared it to the pressure that DevOps faces based on the initial 10 deploys per day concept.

I covered the following topics:

• Components are the dominant pattern for constructing applications.
• Components drive efficiency but introduce risk if not managed properly.
• If DevOps doesn't account for how applications are constructed, DevOps will fail.
• If the release management process doesn't weed out flawed components, DevOps metrics like Defects to Production, MTTR, MTTF will deteriorate / not to mention the business will be at risk!
• The release management process should include support automated security, licensing and architecture policies that guide and enforce action.
• Guidance should be integrated throughout the entire DevOps toolchain (IDE, CI, etc.).
• A sound governance approach shifts activity to the left - vulnerability discovery, fixes, etc.
• Start by identifying an accurate inventory, using policies to identify at risk applications, don't just identify - remediate.

George Lawton wrote a summary of the ignite presentation on ServiceVirtualization.com.

There were many other interesting presentations, and the Open Space concept fostered many timely discussions. Here are my observations from the conference held in Atlanta:

• The conference was dominated by IT Ops discussion. Although this was not surprising given DevOps efforts tend to be driven more by IT Ops than Dev, I hope that DevOps doesn't simply turn into the next generation IT Ops. While initial efforts are focused on the release management process, for DevOps to have a significant impact, it needs equal participation from all constituencies - Dev, QA, IT Ops to start - then expanding to include Security, Compliance, etc.
• Many conversations turn to automation and tooling - even after the initial presentation by Tj Randall, where he noted that DevOps is more than technology, most of the conversations were dominated by what tools to use, what technologies to use, etc. While this is natural given our technology bent, the DevOps impact will be far greater if it is equally focused on process, people and culture.
• While my focus has been on the disconnect between Dev and IT Ops, and Dev and Security, I was reminded that the same disconnect can occur between IT Ops and the network team. Just as the Dev organization sees IT Ops as intractable and risk averse, IT Ops sees the networking team in the same light. It highlights the need to incorporate all constituents into the DevOps process.
• While there are multiple ways to drive DevOps, success is more likely to occur when you have bottom up support. Jim Hirschauer talked about his experience and approach with top down (executive led) or bottom up (passionate supporters), and stated that bottom up support is ultimately needed. He talked about achieving success in small chunks, "story after story" and discussed using lunch and learns, social media, staff meetings, company intranets, etc., to constantly share and reinforce the DevOps message.
• Given the heat around DevOps, organizations are struggling to hire DevOps expertise. Mark White spoke about how we can address this shortage by training existing System Administrators. He explained that we have moved from a culture of being defined by what we knew (Solaris, OpenView, etc.) to understanding how to do things. He said that System Administrators have the background, critical thinking skills, etc., they just need to be trained in the new approaches - Ruby, Python, Puppet, Chef, etc.
• Brian Johnson spoke about ITIL and argued that DevOps was invented by ITIL. I got the impression that he was making a case for ITIL to remain relevant. Although the audience didn't react, I'm not sure that ITIL has the flexibility to be a significant force in agile, DevOps scenarios. He did make some interesting comments on how DevOps should avoid some of the pitfalls that befell ITIL - things like "don't tell everyone that DevOps solves all problems", "don't create a universe of certified experts", etc.

Join us in New York, Vancouver or Portland, if you are in the neighborhood!