Agile.2013.effecting.a.dev ops.transformation.at.salesforce
•
6 likes•9,923 views
Presentation by @davemangot and @kabbyr on the reasons behind, and mechanisms for a DevOps transformation at Salesforce.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Agile.2013.effecting.a.dev ops.transformation.at.salesforce
Similar to Agile.2013.effecting.a.dev ops.transformation.at.salesforce (20)
More from Dave Mangot
More from Dave Mangot (10)
Recently uploaded
Recently uploaded (20)
Agile.2013.effecting.a.dev ops.transformation.at.salesforce
- 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 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. Why are we the same? Why are we different? http://flic.kr/p/eeWbP8 http://flic.kr/p/eeWbGp
- 8. It was the year 2000
- 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, here’s a story of a typical start-up We’ve got an app…
- 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. 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. 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
- 27. Why didn’t 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?
- 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
- 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
- 47. Sharing
- 48. Why are we succeeding?
- 49. The Toyota Way - Kata http://upload.wikimedia.org/wikipedia/commons/7/70/Iaido2.jpg
- 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.”
- 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. Hack Day
- 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. Virtualization
- 62. Why we still have challenges
- 63. Why are you here?
- 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