One Does Not Simply Walk Into Devops


Published on

DevOps is much more than tooling and technical details, it’s first and foremost a cultural and operational shift. This deck was given at, and covers some of the principles and best practices preached for by devops thought leaders such as John Allspaw, Jesse Robbins, Adrian Cockroft, Jez Humble and others.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Motivation, what you won’t find in this talk
  • Devops as teamsShared metrics Incident mgmtService owners on call CI / CD Game day Infra as code: Full stack automation Commodity HW Reliability in SW stack Data center APIs Core infra services: infra as product, app as customer  Application as services: Service orientation Versioned APIs SW resiliency (design for failures) DB storage abstraction Complexity pushed up the stack Deep instrumentation  
  • In amazon every dev runs her own code
  • Push karma
  • Ben talked about it, it’s everyone’s responsibility, including devs
  • Ben mentioned Mark Ibericogithub – undeployed code is lost value
  • Change is a cause for instability
  • Which will allow you to test and rollback changes if needed
  • Roll your own tools - Etsy
  • Talk a bit about the netflix stack – bakery, simian army, asgard
  • Imuutable servers
  • infra as product, app as customer (netflix calls it noops, which pisses of allspaw)
  • Devs thinking about ops
  • Facebook – gatekeeper, wix, etsyCaveat: code can get messy, need to clean up dead code paths methodically
  • Database questions, mention
  • One Does Not Simply Walk Into Devops

    1. 1. SomeBackground
    2. 2. A FewDefinitionAttempts
    3. 3. “stressescommunication &collaboration ...aims to help anorganization rapidlyproduce softwareproducts andservices”
    4. 4. “The DevOpsmovement wasborn of the need toimprove IT servicedelivery agility... “
    5. 5. “Some of that is tools ... A big part of that is culture”Jesse Robbins, OpsCode
    6. 6. “Help me define it…” AdrianCockroft, Netflix
    7. 7. It’s about shipping better software,So… What Is faster & more It about? consistently • Where traditional dev and ops roles fail to deliver
    8. 8. Learn by example, not invent (yet) another definition…
    9. 9. Jesse’s Dev & Ops as Teams Taxonomy (Culture & Processes)(I know, this can also start a flame war…) Infrastructure as Code Application as Services
    10. 10. Accountability • sdf
    11. 11. Devs own their code, so they expect 24x7 contact with it Trust &Responsibility Allspaw’s Take
    12. 12. When things break, dev and ops both participate Trust &Responsibility Allspaw’s Take
    13. 13. Post mortems have dev and ops remediations Trust &Responsibility Allspaw’s Take
    14. 14. “Everyone who has changes going out is accounted for and is actively testing and supporting their changes”Chuck Rossi, Facebook
    15. 15. Definition of Done
    16. 16. “Done means released”Jez Humble
    17. 17. Measure “If it moves, graphEverything it. If it matters, alert on it” Allspaw
    18. 18. Not JustInfrastructure • Measure infra, app and business KPIs • Don’t just measure, correlate
    19. 19.
    20. 20. Paint the Walls
    21. 21. “Ship early, ship often” • Small increments • Undeployed code is lost valueChuck Rossi, Facebook
    22. 22.
    23. 23.
    24. 24.
    25. 25.
    26. 26. 11.6 secondsMean time between deployments1079Max number of deployments / hour10,000Mean number of hosts simultaneouslyreceiving a deployment Source: John Jenkins
    27. 27. Well Defined • Canary tests Rollout • Red/BlackMechanism Deployment • Dark launches
    28. 28.
    29. 29. A Self-Service DataCenter Really Helps(Even more so if it has an API..)
    30. 30. • Infrastructure asThe Common product, app devs to All the as customers – Netflix calls it NoOps, Above but it pisses of Allspaw
    31. 31. • Small services with APIs – Easier to ship, easier to debug, easier to manage at large scale – Caveat: forward and backward compatibility – @adrianco’s “anti- fragility”
    32. 32. • We assume commodity HW,Resiliency in Cloudthe Software • So we have to Stack build reliability into our code
    33. 33. Feature Flips
    34. 34. “Everything is Built for 3”Jeremy Edberg, Netflix
    35. 35. Circuit Breakers (Netflix)
    36. 36. Fire Drills &Monkeys…
    37. 37. What’s Next? – Not everyone is Amazon & Netflix – The next challenge is to make this accessible to all