I was interviewed recently by the folks at Ranger4 for their #DevOpsFriday5 question series. Since June 2014 (when I was interviewed) I have published a couple of things which expand on the original answers, so I have outlined these here. The questions were:
What’s your preferred definition of DevOps?
When people ‘do’ DevOps, what’s the most common mistake you see them make?
How do you recommend an organisation new to DevOps start?
What’s your prediction for what DevOps will look like in 2020?
At the Unicom DevOps Summit event in London on February 28th 2014 we experimented with some extra audience/attendee participation by asking for questions on record cards and encouraged people to ‘dot-vote‘ on the questions most interesting to them. There were some good questions, but unfortunately we did not get chance to discuss many of them, so here are all the questions from the card board, along with some very brief attempts at answers.
Should security be a part of DevOps?
To what extent and how do you insist on standardisation for multiple Scrum + ‘DevOps’ teams with no separate Operations team?
What’s the likely process flow of / disruptions to / duration of DevOps adoption?
Where does ‘Operations’ sit in the ITIL model? All over the place? e.g. Service Transition?
How about some example scenarios? Tangible comparison points would be useful.
Where does DevOps start and finish (from a process perspective)?
Is DevOps just a job title?
Is co-location of resource necessary for successful DevOps?
How essential is cloud technology to DevOps?
How will the announcement that ThoughtWorks are ‘open sourcing’ their Go DevOps product affect other vendor products? Why pay for other products?
There are a lot of open source DevOps/release/orchestration tools – is anyone using (or know about) the Windows equivalent?
How do you overcome developer resistance to writing Run Book docs? Are the processes to drive adoption? Is it a sackable offence?
Update (2019): I have co-authored a book – Team Topologies – that adds brand new material to these (original) DevOps Topologies patterns. In the book we cover dynamic organization evolution, team interaction patterns, the strategic use of Conway’s Law, monolith decomposition, and many more topics.
The new version has many new topologies that we’ve encountered in the wild and we’re taking pull requests on Github for additions and changes.
The primary goal of any DevOps setup within an organisation is to improve the delivery of value for customers and the business, not in itself to reduce costs, increase automation, or drive everything from configuration management; this means that different organisations might need different team structures in order for effective Dev and Ops collaboration to take place.
So what team structure is right for DevOps to flourish? Clearly, there is no magic conformation or team topology which will suit every organisation. However, it is useful to characterise a small number of different models for team structures, some of which suit certain organisations better than others. By exploring the strengths and weaknesses of these team structures (or ‘topologies’), we can identify the team structure which might work best for DevOps practices in our own organisations, taking into account Conway’s Law.
I attended a workshop at DevWeek 2012 led by Neal Ford (@neal4d) on Continuous Delivery (CD). The day was excellent – Neal is a really engaging presenter – and I took copious notes, even though I’d already read most of the CD book. Fifteen months later, I thought it would be interesting to see how my notes from Neal’s workshop compared with my experience of Continuous Delivery, both within my job at thetrainline.com, and also in conversations with other people, particularly the good folks in the London Continuous Delivery meetup group.
The tl;dr version: go attend one of Neal’s excellent CD workshops, but be prepared for the challenges with Continuous Delivery to be much more social/organisational than technical.
Matthew Skelton 