Agile.2013.effecting.a.dev ops.transformation.at.salesforce

8,307 views

Published on

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

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,307
On SlideShare
0
From Embeds
0
Number of Embeds
5,679
Actions
Shares
0
Downloads
69
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Agile.2013.effecting.a.dev ops.transformation.at.salesforce

  1. 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. 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. 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. 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. 5. The 5 Why’s: • Why are we the same? Different? • Why didn’t we transform TechOps on the first try? • Why are we succeeding? • Why we still have challenges • Why are you here?
  6. 6. Why are we the same? Why are we different? http://flic.kr/p/eeWbP8 http://flic.kr/p/eeWbGp
  7. 7. A little story...
  8. 8. It was the year 2000
  9. 9. Number of people
  10. 10. fast innovativesmart
  11. 11. Number of Major Releases per year
  12. 12. 7 years later
  13. 13. rapid success
  14. 14. 59,300+ Customers 10 B transactions/Quarter tons of people
  15. 15. it was getting more difficult to deliver
  16. 16. Features Delivered per Team Days between Major Releases
  17. 17. Number of Major Releases in 2006
  18. 18. 2007 – Birth of ADM
  19. 19. Major R&D wide Agile Transformation to ADM
  20. 20. On time delivery? Last waterfall release
  21. 21. But what about infrastructure?
  22. 22. More importantly, here’s a story of a typical start-up We’ve got an app…
  23. 23. We’ve 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. 24. I’ve got a few more customers… DB Log s Con f Dat a Stat Hlth ID App Oth r FW LB LB FW
  25. 25. Now we’re 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. 26. Salesforce.com Architecture
  27. 27. Why didn’t we transform TechOps on the first try?
  28. 28. Delivering on business priorities Scaling through hiring Still a relatively small team
  29. 29. But then Rapid success continues
  30. 30. 100,000+ Customers 1 B transactions/day tons and tons and tons people
  31. 31. So can we continue to innovate at scale?
  32. 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. 33. Resource Bottlenecks
  34. 34. Lack of responsiveness, lack of team alignment on priorities
  35. 35. Unpredictable completion of projects and initiatives
  36. 36. 2012 – Infrastructure Take 2 ADM + DevOps
  37. 37. Take 2a Developers supporting Operations (part time)
  38. 38. Take 2b Infrastructure Engineering TechOps splits into Operations
  39. 39. Take 2c Clouds Embedded teams
  40. 40. How to use DevOps?
  41. 41. No Crisis
  42. 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. 43. C A M S
  44. 44. Culture
  45. 45. Automation http://upload.wikimedia.org/wikipedia/commons/6/61/Differential_free.png
  46. 46. Metrics http://www.aosabook.org/images/graphite/composer-ui.png
  47. 47. Sharing
  48. 48. Why are we succeeding?
  49. 49. The Toyota Way - Kata http://upload.wikimedia.org/wikipedia/commons/7/70/Iaido2.jpg
  50. 50. ADM for Cultural Change - DevOps Kata •Daily Standup - #8 “Encourage effective two way communication and other means to drive out fear throughout the organization so that everybody may work effectively and more productively for the company.” •Sprint Retrospective - # 13 “Institute a vigorous program of education and self-improvement” •Sprint Demo - #9 “Break down barriers between departments. People in research, design, sales, and production must work as a team, in order to foresee problems of production and usage that may be encountered with the product or service.”
  51. 51. Cloud Realignment http://www.freefoto.com/images/46/01/46_01_49---Clouds_web.jpg
  52. 52. Theory of Constraints as per Goldratt http://images4.wikia.nocookie.net/__cb20080623095705/starwars/it/images/thumb/d /d4/JawaNEGAS.jpg/331px-JawaNEGAS.jpg
  53. 53. Hack Day
  54. 54. Internal DevOps Mini-Conference http://www.flickr.com/photos/gazeronly/7645165306/
  55. 55. Infrastructure Development Lifecycle http://www.freefoto.com/images/46/01/46_01_49---Clouds_web.jpg Artifact Y Deployed to Environment X from release store Test Results marked in ReleaseDB Eligible for promotion to next environment Environment specific tests are Run (increasing clock time) PASS? Ejected from processFAIL? Testing and Deployment
  56. 56. Virtualization
  57. 57. Embeds http://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/Embedded_Artillery_Shell_at_Fort_Sumter_ %287639234388%29.jpg/800px-Embedded_Artillery_Shell_at_Fort_Sumter_%287639234388%29.jpg
  58. 58. Scrum Master Training
  59. 59. Failure? Still? http://theintentionalwriter.com/wp-content/uploads/2013/01/head_in_hands.jpg
  60. 60. Front Door Process http://upload.wikimedia.org/wikipedia/commons/thumb/e/ef/Alnwick_Castle_a_frontal_door.J PG/450px-Alnwick_Castle_a_frontal_door.JPG
  61. 61. Bugs http://upload.wikimedia.org/wikipedia/commons/thumb/9/9b/Cotton_Harlequin_B ugs.jpg/757px-Cotton_Harlequin_Bugs.jpg
  62. 62. Why we still have challenges
  63. 63. Why are you here?
  64. 64. Present and Future Challenges • Bringing Agile into traditional IT Ops • Bringing IT Ops in with Infra Eng and R&D • Re-educating workforce • Recruiting • Scaling Securely

×