Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to choose tools for DevOps and Continuous Delivery - Unicom DevOps Summit Nov 2014 London


Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

How to choose tools for DevOps and Continuous Delivery - Unicom DevOps Summit Nov 2014 London

  1. 1. How to choose tools for DevOps and Continuous Delivery Matthew Skelton, Skelton Thatcher Consulting UNICOM DevOps Summit, 20 November 2014, London#unicomdevops
  2. 2. Collaboration Learning Singleton tools Conway’s Law
  3. 3. Matthew Skelton •Building & operating software systems since 1998 •Cybernetics + Neuroscience + Music •control engineering •psychology •‘network’ and group interactions @matthewpskelton
  4. 4. We help you to transform your technology and teams for ‘the cloud’
  5. 5. Recent clients •Legal •Donations •Tourism •Betting & gambling •Travel booking •Financial data & reporting •Healthcare
  6. 6. Common themes •Online since ~1999 •Successful in their sector •Large, central core database(s) •Non-aligned goals •Need to adopt DevOps and Continuous Delivery
  7. 7. Common needs •Technology selection ticklists •Team interactions •Collaboration opportunities •Tools as catalysts
  8. 8. Continuous Delivery •A scientific approach to changing software systems (Dave Farley) •Regular, rapid, repeatable, reliable changes
  9. 9. Continuous Delivery •Quality •Safety •Reliability •Psychology •Effectiveness
  10. 10. 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.
  11. 11. Not DevOps “Automation” “Build & Release” “Infrastructure Development” “System Administration”
  12. 12. Collaboration
  13. 13. 1. Version Control
  14. 14. 2. Deployment Pipeline
  15. 15. A large online retailer •Travel sector •Since ~1999 •UK market •‘Non-core’ applications
  16. 16. Challenges were: •Limited Git skills in Service team •Manual deployments •‘Snowflake’ servers •No CI •Risks: security, automation, etc
  17. 17.
  18. 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. 19. Results •Security: happy •Service team: relieved (& happy) •Developers: won over (& happy) •Business: surprised (& happy)
  20. 20. 3. Log Aggregation
  21. 21. LogStash •ElasticSearch+ LogStash+ Kibana •ELK •In Production, Pre-Prod, Test •On developer machines!!!
  22. 22.
  23. 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. 24. Learning
  25. 25. Learning & tool choice Bring people with you Appreciate current skills Prefer achievable gains now Avoid fear of too-scary tools
  26. 26. Singleton tools (or the ‘Prize Bull’ approach)
  27. 27. Singleton tools •Special database server •Costly log aggregation •Costly monitoring •Server configuration
  28. 28.
  29. 29. “Better features”? Optimise globally across the teams that need to collaborate
  30. 30. Singleton tool Breaks feedback (learning) loop from Production Makes CI/CD more difficult Underestimates value of collaboration and learning
  31. 31. Conway’s Law
  32. 32. Mel Conway, 1968 “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
  33. 33. Ruth Malan, 2008 “if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins”
  34. 34. DevOps Topologies
  35. 35. DevOps Topologies
  36. 36. DevOps Topologies
  37. 37. DevOps Topologies
  38. 38. Conway & Tool Choice See the organisation as a system Separate tools for separate teams Shared tools for collaborative teams
  39. 39. Conway’s Law •Allan Kelly -@allankellynet •
  40. 40. 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!)
  41. 41. Further reading Build Quality In 70% of royalties donated to Code Club Discount for #unicomdevops: c/Unicom2014 Contributors from Unicom events: -James Betteley -Chris O’Dell -NiekBartholomeus -John Clapham
  42. 42. Thank you / @matthewpskelton HT: @Squire_Matt, @alan_parkinson