Successfully reported this slideshow.
Your SlideShare is downloading. ×

One Does Not Simply Walk Into Devops

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 49 Ad

One Does Not Simply Walk Into Devops

DevOps is much more than tooling and technical details, it’s first and foremost a cultural and operational shift. This deck was given at www.devopscon.com, 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.

DevOps is much more than tooling and technical details, it’s first and foremost a cultural and operational shift. This deck was given at www.devopscon.com, 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.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to One Does Not Simply Walk Into Devops (20)

More from Uri Cohen (20)

Advertisement

One Does Not Simply Walk Into Devops

  1. 1. Some Background
  2. 2. A Few Definition Attempts
  3. 3. “stresses communication & collaboration ... aims to help an organization rapidly produce software products and services”
  4. 4. “The DevOps movement was born of the need to improve IT service delivery agility... “
  5. 5. “Some of that is tools ... A big part of that is culture” Jesse Robbins, OpsCode
  6. 6. “Help me define it…” Adrian Cockroft, 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 http://www.slideshare.net/jezhumble/scaling-devops
  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 http://www.slideshare.net/jesserobbins/hacking-culture-at-velocityconf
  16. 16. “Done means released” Jez Humble
  17. 17. Measure “If it moves, graph Everything it. If it matters, alert on it” Allspaw
  18. 18. Not Just Infrastructure • Measure infra, app and business KPIs • Don’t just measure, correlate
  19. 19. http://www.slideshare.net/jallspaw/dev-and-ops-collaboration-and-awareness-at-etsy-and-flickr
  20. 20. Paint the Walls http://www.slideshare.net/realgenekim/2012-velocity-london-devops-patterns-distilled
  21. 21. “Ship early, ship often” • Small increments • Undeployed code is lost value Chuck Rossi, Facebook
  22. 22. http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change
  23. 23. http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change
  24. 24. http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change
  25. 25. http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change
  26. 26. 11.6 seconds Mean time between deployments 1079 Max number of deployments / hour 10,000 Mean number of hosts simultaneously receiving a deployment Source: John Jenkins
  27. 27. Well Defined • Canary tests Rollout • Red/Black Mechanism Deployment • Dark launches
  28. 28. http://www.slideshare.net/bitfield/agile-sysadmin-and-the-art-of-infrastructure-automation-2493286
  29. 29. A Self- Service Data Center Really Helps (Even more so if it has an API..)
  30. 30. • Infrastructure as The 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 Cloud the Software • So we have to Stack build reliability into our code
  33. 33. Feature Flips http://www.flickr.com/photos/maxabxarata/535048895/
  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

Editor's Notes

  • 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

×