This post was written by Rob Thatcher, co-author of Team Guide to Software Operability.
Today we attended the Rackspace-hosted #DevOpsBreakfast briefing in London, with my colleague Matthew Skelton taking an active seat on the panel, to debate the ‘what, why, and how’ of DevOps. The discussion was wide-ranging, with plenty of participation from the audience, and some lively counter questions supplied by the mediator Paul Miller. We’ve collated some of the points, and amalgamated in some thinking around the subject below.
Paul opened the discussion, by asking Chris Jackson of Rackspace to define DevOps. Chris’s definition came out something along the lines of
collaboration to drive effectiveness, connect IT to [the] business and increase value
This is not a million miles from our own attempt at a working definition of DevOps:
Highly effective, daily collaboration between software developers and IT operations people to produce relevant, working systems
To the amusement of some members of the audience, Paul suggested this was akin to a ‘lack of top down control, empowering developers to break mission critical systems’.
We still need Operations
Steve Thair from DevOpsGuys, quickly jumped on that assertion, stating that DevOps is trying to propose an alternative to rigid Prince 2 / ITIL driven practices, reminding us in no uncertain terms that
We still need Operations [Ops] … Ops is a discipline, in the same way Software development is a discipline. Starting a separate DevOps team is creating another silo and missing the point
Find a candidate software application for a prototype DevOps approach
Paul then asked “does this might mean that doing DevOps is too big to handle?”
My colleague Matthew pointed out that that organisations must be set up to understand that “modern software systems must evolve over time, and a key enabler for evolving software systems is to use DevOps to encourage the flow of metrics-based intelligence back to developers from Production.” In practical terms organisations making the switch to DevOps should look to take a small ‘non-critical’ but valuable software application or service and apply the DevOps approach to it. Chris Jackson noted that Rackspace often work with their customers to find such ‘candidate applications’ for a prototype DevOps adoption. As part of that process they look for friction points within the organisation. When choosing tools for DevOps it is important to assess how the tools will help (or hinder) collaboration between different teams – this is something we have spoken about recently at DevOps Exchange meetup group:
Stop firefighting, start delivering
Steve Acreman from Dataloop.io observed that a good way to kickstart a DevOps adoption is for the Ops team to build and provide a self-service deployment capability for the Dev teams to use, which frees up Ops people to focus on valuable activities such as advanced monitoring and trend analysis. Steve Thair agreed: Ops teams can be so busy ‘fire-fighting’ that they haven’t had the chance to discover more effective approaches like DevOps or even the wider tech community. This is a phenomenon we have observed in the SME space recently; in one organisation, the techies were so involved in manual fixes that they had never been to meetup groups or conferences and were consequently out of touch with modern practices.
API-rich tooling
The discussion wound up by discussing the work to be done in defining a good ‘starter’ DevOps toolchain, which would help to power understanding even at the technical level. For instance, a good technical demonstration can win over cynical staff from both Ops and Development and “open people’s eyes” to what is now possible with modern lightweight, API-rich tooling. Chris Jackson hit the mark noting that we should be working to ‘reduce opinion, and increase value’ when deciding on which of several largely equivalent tools to use.
Summary
It was great to be part of the DevOpsBreakfast discussion. There were many interesting and searching questions from the audience, as well as useful opinions and experience shared by the panellists. It’s clear that a shared understanding of DevOps is beginning to coalesce around the combination of technology AND teams delivering valuable working systems with rapid feedback but without a blame culture. Kudos to Rackspace and Red for organising the session, to all panellists, and to the attendees.
There is more on the Twitter hastag #DevOpsBreakfast
Skelton Thatcher 