DevOps Breakfast with Rackspace – expanding on ‘What is DevOps?’

Rackspace DevOpsBreakfast 19th August 2014

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

Rackspace DevOpsBreakfast 19th August 2014
The panel debate – photo by @zuzanabielikova

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 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.


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

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: