Uploaded byJohn Barton
Dev Ops @ Envato
The document discusses Envato's approach to DevOps, highlighting how a team of eight efficiently deploys a Ruby on Rails application handling 20 million requests weekly without a dedicated ops team. Key decisions include preserving startup culture, conservative platform choices, and ensuring that all team members own their work and support responsibilities. It emphasizes continuous deployment, automation, and a culture of accountability while acknowledging trade-offs made for the sake of speed and product innovation.
More Related Content
![Governance, Deployment & Methodologies for Agentic Automation [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/agenticcommunityseries-day2-251112135038-a386476d-thumbnail.jpg?width=640&height=640&fit=bounds)
Dev Ops @ Envato
- 1. Dev Ops @Envato ... or how we found out there’s a name and a support group for all the stuff we already did to let a team of 8 deploy heaps of times a day to a Ruby on Rails app that has scaled up to around 20 million requests a week without an ops team.
- 2.
- 3.
- 4. Stock Marketplaces & Tutorial Network
- 5.
- 6. Like iStockPhoto butfor other creative niches or eBay for digital goods
- 7.
- 8. Big Blog Networkfor education in creative fields.... and linkbait (ducks)
- 9. Big traffic andinteresting in it’s own right, but that’s for @ryanfaceryan to talk about
- 10.
- 11. 2 things recentlymade us think we might be doing something a bit different
- 12. Neal Ford @YOW! “Rails can Scale”
- 13. 200k+ daily requests vs 2m+ daily requests
- 14. Dev Ops Melbourne “ContinuousDeployment”
- 15. 1 Deployment perweek or fortnight vs 5 Deployments per Day
- 16.
- 17.
- 18.
- 19.
- 20. Rails 0.13b No Users NoTraffic
- 21.
- 22.
- 23. ActiveDen (nee FlashDen) AudioJungle ThemeForest VideoHive GraphicRiver CodeCanyon 3D Ocean Tuts+ Marketplace PhotoDune
- 24. Rails 2.3.11 687,830 Users 20 Million Requests Weekly
- 25. One Codebase andOne Production Environment
- 26. ... and wellgosh darn it we just deploy to that site whenever we darned well feel like it
- 27. As much aproduct of time and circumstances as good decisions and hard work
- 28.
- 30. 3 Developers 30 minutefeedback cycle deploy, discuss on forums, deploy again
- 31. Decision 1: Preserve everythinggood about the the startup days for as long as we can
- 32.
- 33. Notice I’m notsaying “Cloud Computing”
- 36. You can't trust “the cloud”but you can trust “the cloud to be “the cloud”.
- 37. Decision 2: Conservative Platform choice so we don’t have to sweat the details
- 38.
- 39. We’ve all beendoing dev long enough to see this stuff screwed up over and over again
- 40. Decision 3: Don’t doall that stuff
- 41. So what dowe actually do?
- 42. “Culture of respect& trust, good attitude toward failure...” Ted Dzubia
- 43. “How about "cultureof stop fucking up"?” Ted Dzubia http://teddziuba.com/2011/03/devops-scam.html
- 44.
- 45. "The fault, dear Brutus,is not in our QA or Ops, But in ourselves."
- 46. Test Driven Development vs. QA Team
- 47. Test Driven Infrastructure vs. Ops Team
- 48. Both as ateam and as individuals we own our work from when we are asked to do it...
- 49. ... until isis demonstrably error free and performant in production
- 50. Everyone is inthe (paid) on call roster
- 51. Everyone takes aturn at Level 2 Customer Support
- 52. Want those jobsto be easier? Stop fucking up.
- 53.
- 54. LEAN / TPSPrinciples ...without the process
- 56. You cannot writecode any faster than you can deploy it to production
- 57.
- 58. A. B. C. AlwaysBe Cmerging (the c is silent)
- 59.
- 60.
- 61. We do tripup running this fast
- 62. But through yearsof openness with our users via our forums and owning up to our mistakes
- 63. ... we’ve endedup with a (relatively) sympathetic community
- 64. Time Zones bothhelp and hurt
- 65. Traffic peaks duringUS day means that if things go wrong we’re usually asleep
- 66. But it makesit very easy to deploy during our business hours
- 67.
- 68.
- 69. Outsource commodity platform bits: virtualisation/cloud, have rackspace take care of db/ mailserver
- 70. Ensure the devteam has the skills to take care of the rest
- 71. Keep the stackas Vanilla as possible
- 72. Virtualised servers inour own sandbox. Cloud Flexibility - Cloud Shit-ness = WIN
- 73. Automate Configuration Management
- 74. Don’t modify liveboxes, tear down and build again from scratch
- 75. Take advantage ofan individual's talents, but don’t rely upon them ie. don’t accidentally create an ops guy
- 76.
- 77. Not as biga deal as everyone thinks
- 78. Shared-nothing load balanced appservers + out of request queue workers not rocket surgery
- 79. Measure, deploy, measure againand then tweak or rollback New Relic FTW
- 80. There is nocode faster than no code.
- 81.
- 82. We rely onour growth following a steady exponent for this approach to be viable
- 83. We made aconscious tradeoff between delivery time and production snafus
- 84. We’ve traded offplatform innovation for product innovation (no MongoDB, etc)
- 85. Auditors aren’t bigfans of one team with access to everything, but you can mitigate these problems
- 86.
Editor's Notes
- #2 \n
- #3 \n
- #4 \n
- #5 \n
- #6 \n
- #7 \n
- #8 \n
- #9 \n
- #10 \n
- #11 \n
- #12 \n
- #13 \n
- #14 \n
- #15 \n
- #16 \n
- #17 \n
- #18 \n
- #19 \n
- #20 \n
- #21 \n
- #22 \n
- #23 \n
- #24 \n
- #25 \n
- #26 \n
- #27 \n
- #28 \n
- #29 \n
- #30 \n
- #31 \n
- #32 \n
- #33 \n
- #34 \n
- #35 \n
- #36 \n
- #37 \n
- #38 \n
- #39 \n
- #40 \n
- #41 \n
- #42 \n
- #43 \n
- #44 \n
- #45 \n
- #46 \n
- #47 \n
- #48 \n
- #49 \n
- #50 \n
- #51 \n
- #52 \n
- #53 \n
- #54 \n
- #55 \n
- #56 \n
- #57 \n
- #58 \n
- #59 \n
- #60 \n
- #61 \n
- #62 \n
- #63 \n
- #64 \n
- #65 \n
- #66 \n
- #67 \n
- #68 \n
- #69 \n
- #70 \n
- #71 \n
- #72 \n
- #73 \n
- #74 \n
- #75 \n
- #76 \n
- #77 \n
- #78 \n
- #79 \n
- #80 \n
- #81 \n
- #82 \n
- #83 \n
- #84 \n
- #85 \n
- #86 \n
- #87 \n