Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Summary:  Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.

I captured my notes as slides:

Update: the video of Pete’s talk is here on Vimeo:

Pete Mounce video frame

There were several specific points made by Pete that were interesting for me:

Continue reading Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Continuous Delivery for databases: microservices, team structures, and Conway’s Law

The way we think about data and databases must adapt to fit with dynamic cloud infrastructure and Continuous Delivery. The need for rapid deployments and feedback from software changes combined with an increase in complexity of modern distributed systems and powerful new tooling are together driving significant changes to the way we design, build, and operate software systems. These changes require new ways of writing code, new team structures, and new ownership models for software systems, all of which in turn have implications for data and databases.

Read the full article on Simple Talk: Continuous Delivery for Databases: Microservices, Team Structures, and Conway’s Law.

(These slides were presented in a talk I gave at develop:BBC 2014 conference on 13th November in London)

Deployability for databases for Continuous Delivery – article on Simple Talk

I wrote an article recently for the Simple Talk website called Common database deployment blockers and Continuous Delivery headaches, where I outline some of the common problems preventing databases from being deployable – a major blocker to Continuous Delivery.

Deployability is now a first-class concern for databases, and there are several technical choices (conscious and accidental) which band together to block the deployability of databases. Can we improve database deployability and enable true Continuous Delivery for our software systems? Of course we can, but first we have to see the problems.

The recommendations include:

  1. Minimize changes in Production
  2. Reduce accidental complexity
  3. Archive, distinguish, and split data
  4. Name things transparently
  5. Source Business Intelligence from a data warehouse
  6. Value more highly the need for change
  7. Avoid Production-only tooling and config where possible [I mention this in my talk How to choose tools for DevOps and Continuous Delivery]

To address [these things] individually perhaps doesn’t seem too challenging, but to tackle deployability requires close, effective collaboration between developers, DBAs, and operations teams to achieve the right balance between rapid deployment and access to data.

Deployability for Databases

Read the full article herehttps://www.simple-talk.com/sql/database-administration/common-database-deployment-blockers-and-continuous-delivery-headaches/

The most common DevOps adoption mistake, and other answers – interview for DevOpsFriday5

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:

  1. What’s your preferred definition of DevOps?
  2. When people ‘do’ DevOps, what’s the most common mistake you see them make?
  3. How do you recommend an organisation new to DevOps start?
  4. What’s your prediction for what DevOps will look like in 2020?
  5. Where do you like to go to get a DevOps hit?

Continue reading The most common DevOps adoption mistake, and other answers – interview for DevOpsFriday5

DevOps Questions from Unicom DevOps Summit Feb 2014

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?

Continue reading DevOps Questions from Unicom DevOps Summit Feb 2014