The Frontiers of Continuous Delivery

Continuous Delivery solves many current challenges - but still adoption is limited. This talks shows reasons for this and how to overcome these problems.

Transcript

1. Eberhard Wolff Fellow INNOQ @ewolff http://ewolff.com
2. http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/
3. http://microservices-buch.de/ http://microservices-book.com/
4. http://microservices-buch.de/ ueberblick.html http://microservices-book.com/ primer.html FREE!!!!
5. http://microservices-praxisbuch.de http://practical-microservices.com/
6. http://microservices-praxisbuch.de/ rezepte.html http://practical-microservices.com/ recipes.html FREE!!!!
7. Continuous Delivery – Why Do I Even Care?
8. Faster Feedback Implementation Production Deployment
9. Lower Risk • Each deployment contains less changes • Lower risk of a bug • Easier to fall back • …or add other safeguards Quarterly Release Daily Release
10. Higher Reliability • Automated deployment and tests • …easy to reproduce • ...faster • ...executed frequently Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release
11. Principles Agile Manifesto Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
12. Continuous Delivery: Why Do I Even Care? • Faster Feedback • Lower Risk • Higher Reliability • Value to the customer • I’m in!
14. 2010: Continuous Delivery is the next big thing!
15. Continuous Delivery will increase productivity!
16. Continuous Delivery should obviously be the way to go.
17. Continuous Delivery: A Proven Success! • Correlation and causalation between • …high deployment frequency • ..low lead time for change • …low change failure rate • Fast and low risk go together!
18. Continuous Delivery A Proven Success! • 2017 State of DevOps Reports by DORA based on 27.000 surveys • Failure rate multiple deploys a day: 0-15% • Failure rate once a week to once a month: 31-45% • https://puppet.com/resources/whitepaper/state- of-devops-report
19. Continuous Delivery Proven Success! • Nicole Forsgen / Jez Humble / Gene Kim: Accelerate
20. Provable Fast and Low Risk Pic: Eberhard Wolff
21. Continuous Delivery = Technical Issue
22. Continuous Delivery = Technical Issue Deployment
23. Continuous Delivery = Technical Issue Deployment No!!!!!
24. 2017: Lots of tools to solve technical issues.
25. Continuous Delivery is People.
27. Frontier: Business
28. Faster Feedback Implementation Production Deployment Business Metrics Business Features
29. How Business Works • Release Q1/2018 • Here are the features! • Go!
30. 60%– 90% of ideas do not improve the metrics they were intended to improve Ronny Kohavi Former Head Data Mining and Personalization Group Amazon Source: Lean Enterprise, Humble et al
31. Just Waste • More than half of the features are worthless… • ...or hurt business goals. • Many businesses doesn’t even know the KPIs.
32. Run a minimal feature by users. Implementation Production Deployment Business Metrics Business Features Related to MVP (Minimal Viable Product)
33. Survival is Optional.
34. • Fast releases lead to better software and products. • Bad products die out. • Continuous delivery: The only way to succeed for a business.
35. IT Chauvinism
36. Ways to Compete • More features faster • …or... • Trust • Existing customer relations • Would your grandpa choose a FinTech over a bank?
37. Other Reasons for Continuous Delivery?
38. No Continuous Delivery • Diesel update at VW and Audi • 4.000.000 cars going to the garage just for a software update. • How much does that cost? • Per car 70€ • Total 280.000.000€ https://heise.de/newsticker/meldung/Volkswagen-Haendler-Software-Update-taugt-nicht-3834343.html http://www.handelsblatt.com/my/unternehmen/industrie/volkswagen-vier-millionen-diesel-autos-erhalten-update/20139344.html
39. Continuous Delivery • Tesla • Over the air updates • New features like • …more speed • …more range during hurricane Irma • …autonomous driving • ...summoning Pic: Steve Jurvetson, Wikipedia
40. Continuous Delivery: Yes • What about these cars is not software? Pic: Steve Jurvetson, Wikipedia
41. Even for cars most features are software now.
42. Even for cars most features are software now. Even for cars you can do continuous delivery.
43. Provable Fast and Low Risk Pic: Eberhard Wolff
44. But we build embedded software!
45. But we build embedded software! We need safety!
46. But we build embedded software! We need safety! Delivering often is risky!
47. Provable Fast and Low Risk Pic: Eberhard Wolff
48. No Continuous Delivery • Like Schufa or Creditreform in Germany • Breach: Data of 143 million Americans (44%) • Hacked in May 2017 • Security fix for Struts available since March 2017 • Get fixes out without Continuous Delivery? • Continuous Delivery is safer.
49. But we build embedded software! We need safety!
50. But we build embedded software! We need safety! How many (Cash) Machines still run XP?
51. So you really don’t see any value in Continuous Delivery?
52. So you really don’t see any value in Continuous Delivery? You really can’t do Continuous Delivery?
53. So you really don’t see any value in Continuous Delivery? You really can’t do Continuous Delivery? Or is it just excuses?
54. Business • …could get the biggest benefit • ...but often doesn‘t • Product development in small batches is different from the known ways… • ...and some businesses are not under a lot of pressure.
55. Extending the frontier
56. Is Continuous Delivery worth it without business support?
57. YES!!
58. • Faster Feedback • Lower Risk • Higher Reliability • Value to the customer
59. Extending the Business Frontier • Ambitious: IT drives the business • Not too much influence? • IT sometimes only think they know better. • Educate business • …or focus on other benefits
60. Frontier: People
61. Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release QA Dev Ops Customer
62. QA & CD • Quality Assurance (QA) must provide tests • …or at least support testing • Automated tests • Manual tests too slow • …and too error prone QA
63. QA & CD • Traditional Quality Assurance (QA) focuses on manual tests. • Mind shift • …and different skills QA
64. Customer • Customer must provide information for automated acceptance test • No more manual sign-off • Needs trust • …and trust! • ...and some technical literacy Customer
65. Ops • One month waiting for a database • …that is cheaply provided • …by a highly optimized Ops team • …for “cost” • Ops has very different incentives • …and doesn‘t work in projects. Ops
66. Dev • Can automate • i.e. develop software • …but have limited knowledge about QA and Ops. Dev
67. Software = Automation
68. Software = Automation Still automating CD is hard!
69. Extending the frontier
70. Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release QA Dev Ops Customer
71. Educate & Collaborate • Dev do automation all day. • Make all aware of the needed collaboration • Encourage collaboration • Not necessarily an org chart change
72. Ops Dev Why the heck all the servers? What do you even know about architecture? Is reorganization really the solution?
73. Ops Dev Let’s reduce Critical bugs in production! QA Reduced critical bugs by >50%. Collaboration despite org separation
74. Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Dev Dev Dev Dev
75. Dev • Dev takes over the other roles. • Happening in practice • …but not a strategy • Unused QA / Ops skills Dev
76. 2012: Talk about Linux namespaces, AuFS and cgroups at a developer conference?
77. 2012: Talk about Linux namespaces, AuFS and cgroups at a developer conference? 2018: Docker at every developer conference
78. Dev is learning Ops skills.
79. Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release QA Dev Ops Customer
80. Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release QA Dev Customer
81. PaaS • Cloud Foundry, Openshift, Kubernetes • Install a PaaS once (challenge) • All future deployments via PaaS • Technology to solve the social DevOps issue • …but is there any disadvantage?
82. Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release QA Dev Ops Customer
83. Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release QA Dev Customer
84. Public Cloud • Two minutes for a database instead of one month • Many predefined offerings for Big Data, messaging… • ...but off premise
85. Public Cloud • “But we cannot possibly run in the cloud!” • A problem or a strategy by Ops to keep their job? • Large corporations are looking seriously into this! • Ops strategy probably failing.
86. Cross-functional Team • Was: teams with broad skill set • i.e. frontend, backend, database • Benefits agility: Can work on meaningful business features Frontend Backend Database
87. More Cross-functional Team • Include QA, Ops • …even business • Might build guilds to foster knowledge exchange • Spotify Dev QA Ops Business
88. More Cross-functional Team • Can be led by business goals • Can enable self organization • Huge organizational shift • What happened to managers??? • Management buy-in? Dev QA Ops Business
89. Frontier: Management Buy-in
90. Just like Agility
91. Agility in the Nineties • Grassroots movement • The future of development! • Teams want to do it. • Management: Na, how can you delivery software without a huge sophisticated plan?
92. Agility Now • Management: We do Scrum • Teams skeptical or uninterested • Business finds it hard to reap the benefits • Still traditional product development.
93. Agility Now • Need more than lip service • …convincing • http://blog.johanneslink.net/ 2011/12/02/say-goodbye-i-wont-be-back/
94. Just Start Continuous Delivery.
95. It's easier to ask forgiveness than it is to get permission. Grace Hopper Pic: Wikipedia
96. Extending the frontier
97. CD & Management Buy-In • Management buy-in won‘t solve the problems! • It just means there will be other problems. • Still: try to convince management.
98. Conclusion
99. Conclusion • Technological problems mostly solved • Microservices might support Continuous Delivery.
101. Continuous Delivery is People.
102. Gerald Weinberg‘s 2nd Law of Consulting: No matter how it looks at first, it's always a people problem.
103. • EMail jax2018@ewolff.com to get: • Slides • + Microservices Primer DE / EN • + Microservices Recipes DE / EN • + Sample Microservices Book DE / EN • + Sample Practical Microservices DE/EN • + Sample of Continuous Delivery Book DE • Powered by Amazon Lambda & Microservices