Matthew Skelton - How to choose tools for DevOps - collaboration over automation
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Matthew Skelton - How to choose tools for DevOps - collaboration over automation

Uploaded on | @matthewpskelton ... | @matthewpskelton

Title: How to choose tools for DevOps - collaboration over automation

Matthew Skelton has been building, deploying, and operating commercial software systems since 1998. Co-founder and Principal Consultant at Skelton Thatcher Consulting Ltd, he specialises in helping organisations to adopt and sustain good practices for building and operating software systems: Continuous Delivery, DevOps, aspects of ITIL, and software operability. Matthew founded and leads the 700-member London Continuous Delivery meetup group (, and instigated the first conference in Europe dedicated to Continuous Delivery, PIPELINE Conference ( He also co-facilitates the popular Experience DevOps workshop series (

With an ever-increasing array of tools and technologies claiming to 'enable DevOps', how do we know which tools to try or to choose? In-house, open source, or commercial? Ruby or shell? Dedicated or plugins? It transpires that highly collaborative practices such as DevOps and Continuous Delivery require new ways of assessing tools and technologies in order to avoid creating new silos. Matthew Skelton shares his recent experience of helping many different organisations to evaluate and select tools to facilitate DevOps; the recommendations may surprise you.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 472 467 3 1 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. How to choose tools for DevOps and Continuous Delivery Matthew Skelton, Skelton Thatcher Consulting DevOps Exchange meetup group, 24 July 2014, London, UK #doxlon
  • 2. Collaboration Learning Singleton tools Conway’s Law
  • 3. Matthew Skelton •15 years building & operating software systems •Cybernetics + Neuroscience • control engineering • psychology • ‘network’ interactions @matthewpskelton
  • 4. PIPELINE Conference London Continuous Delivery meetup group (#londoncd)
  • 5. Help orgs to adopt and sustain good engineering practices Interim CTO/Head of X, tech strategy, architecture, workshops, delivery
  • 6. Recent clients •Tourism •Betting & gambling •Travel booking •Financial data & reporting •Healthcare
  • 7. Common themes •Online since ~1999 •Successful in their sector •Large, central core database(s) •Non-aligned goals •Need to adopt DevOps and Continuous Delivery
  • 8. Common needs •Technology selection ticklists •Team interactions •Collaboration opportunities •Tools as catalysts
  • 9. Continuous Delivery •A scientific approach to changing software systems (Dave Farley) •Regular, rapid, repeatable, reliable changes
  • 10. Continuous Delivery •Quality •Safety •Reliability •Psychology •Effectiveness
  • 11. DevOps “Highly effective, daily collaboration between software developers and IT operations people to produce relevant, working systems” * *also QA/Testing, IT Service Desk, Programme Management, Commercial, Marketing, etc.
  • 12. Not DevOps “Automation” “Build & Release” “Infrastructure Development” “System Administration”
  • 13. Collaboration
  • 14. 1. Version Control
  • 15. 2. Deployment Pipeline
  • 16. Challenges were: •Limited Git skills in Service team •Manual deployments •‘Snowflake’ servers •No CI •Risks: security, automation, etc
  • 17.
  • 18. What we did •Built a walking skeleton pipeline •Modelled security roles and stages •Included manual steps (at first) •Walked people through steps •Finally: opened firewall so everyone could see the UI
  • 19. Results •Security: happy •Service team: relieved (& happy) •Developers: won over (& happy) •Business: surprised (& happy)
  • 20. 3. Log Aggregation
  • 21. LogStash •ElasticSearch+ LogStash+ Kibana •ELK •In Production, Pre-Prod, Test •On developer machines!!!
  • 22.
  • 23. Collaboration & tool choice Value collaboration as a key criterion Orthogonal to main purpose (?) “How does [the use of] this tool help people to collaborate?”
  • 24. Learning
  • 25. Learning & tool choice Bring people with you Appreciate current skills Prefer achievable gains now Avoid fear of too-scary tools
  • 26. Singleton tools (or the ‘Prize Bull’ approach)
  • 27. Singleton tools •Special database server •Costly log aggregation •Costly monitoring •Server configuration
  • 28.
  • 29. “Better features”? Optimise globally across the teams that need to collaborate
  • 30. Singleton tool Breaks feedback (learning) loop from Production Makes CI/CD more difficult Underestimates value of collaboration and learning
  • 31. Conway’s Law
  • 32. Mel Conway, 1968 “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
  • 33. DevOps Topologies
  • 34. DevOps Topologies
  • 35. DevOps Topologies
  • 36. DevOps Topologies
  • 37. Conway & Tool Choice See the organisation as a system Separate tools for separate teams Shared tools for collaborative teams
  • 38. Conway’s Law •Allan Kelly - @allankellynet •
  • 39. How to choose tools for DevOps Value collaboration aspects Avoid a learning mountain: evolve tooling Avoid Production-only tools Consider Conway’s Law (this list is incomplete!)
  • 40. Further reading HighOps Operability eBook Build Quality In
  • 41. Thank you / @matthewpskelton HT: @Squire_Matt, @alan_parkinson