Agile.2013.effecting.a.dev ops.

download Agile.2013.effecting.a.dev ops.

of 65

  • date post

    11-Nov-2014
  • Category

    Technology

  • view

    6.917
  • download

    0

Embed Size (px)

description

Presentation by @davemangot and @kabbyr on the reasons behind, and mechanisms for a DevOps transformation at Salesforce.

Transcript of Agile.2013.effecting.a.dev ops.

  • 1. Effecting a DevOps Transformation at Salesforce.com Agile 2013 Dave Mangot Architect, Infrastructure Engineering @davemangot in/dmangot Karthik Rajan VP, Infrastructure Engineering @kabbyr in/karthikrajan
  • 2. Safe Harbor Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services. The risks and uncertainties referred to above include but are not limited to risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site. Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
  • 3. Karthik Rajan Responsible for the infrastructure platform for running the salesforce.com service - Infrastructure as Code 5 years @ salesforce.com, in various roles - developer to management Photographer. Petrolhead. Collector of many many gadgets
  • 4. Dave Mangot Mainly focused on automation, monitoring, orchestration and lastly...cultural change! Systems Engineer 15+ years, a variety of companies big (Cable & Wireless, Sun Microsystems) and small (Tagged.com, Terracotta)
  • 5. The 5 Whys: Why are we the same? Different? Why didnt we transform TechOps on the first try? Why are we succeeding? Why we still have challenges Why are you here?
  • 6. Why are we the same? Why are we different? http://flic.kr/p/eeWbP8 http://flic.kr/p/eeWbGp
  • 7. A little story...
  • 8. It was the year 2000
  • 9. Number of people
  • 10. fast innovativesmart
  • 11. Number of Major Releases per year
  • 12. 7 years later
  • 13. rapid success
  • 14. 59,300+ Customers 10 B transactions/Quarter tons of people
  • 15. it was getting more difficult to deliver
  • 16. Features Delivered per Team Days between Major Releases
  • 17. Number of Major Releases in 2006
  • 18. 2007 Birth of ADM
  • 19. Major R&D wide Agile Transformation to ADM
  • 20. On time delivery? Last waterfall release
  • 21. But what about infrastructure?
  • 22. More importantly, heres a story of a typical start-up Weve got an app
  • 23. Weve got a customer or two Web DB Log s Con f Dat a Stat Hlth ID App Oth r App Log s Con f Dat a Stat Hlth ID App Oth r Log s Con f Dat a Stat Hlth ID App Oth r Customer Admin
  • 24. Ive got a few more customers DB Log s Con f Dat a Stat Hlth ID App Oth r FW LB LB FW
  • 25. Now were making money DB Log s Con f Dat a Stat Hlth ID App Oth r FW LB LB FW FW FW FW FW LB LB LB LB DB Log s Con f Dat a Stat Hlth ID App Oth r
  • 26. Salesforce.com Architecture
  • 27. Why didnt we transform TechOps on the first try?
  • 28. Delivering on business priorities Scaling through hiring Still a relatively small team
  • 29. But then Rapid success continues
  • 30. 100,000+ Customers 1 B transactions/day tons and tons and tons people
  • 31. So can we continue to innovate at scale?
  • 32. Lack of visibility http://upload.wikimedia.org/wikipedia/commons/thumb/4/46/Morning_Fog_at_GGB.JPG/448px- Morning_Fog_at_GGB.JPG
  • 33. Resource Bottlenecks
  • 34. Lack of responsiveness, lack of team alignment on priorities
  • 35. Unpredictable completion of projects and initiatives
  • 36. 2012 Infrastructure Take 2 ADM + DevOps
  • 37. Take 2a Developers supporting Operations (part time)
  • 38. Take 2b Infrastructure Engineering TechOps splits into Operations
  • 39. Take 2c Clouds Embedded teams
  • 40. How to use DevOps?
  • 41. No Crisis
  • 42. The 3 Ways Gene Kim The First Way emphasizes the performance of the entire system The Second Way is about creating the right to left feedback loops. The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure;
  • 43. C A M S
  • 44. Culture
  • 45. Automation http://upload.wikimedia.org/wikipedia/commons/6/61/Differential_free.png
  • 46. Metrics http://www.aosabook.org/images/graphite/composer-ui.png