Continuous Delivery and DevOps in the Enterprise

4,591 views

Published on

Published in: Technology, Business

Continuous Delivery and DevOps in the Enterprise

  1. 1. DevOps & Continuous Delivery in the Enterprise Eberhard Wolff - @ewolff
  2. 2. I am an Enterprise & Java guy Eberhard Wolff - @ewolff …so I know the Enterprise side of things. And at least I know the technical side of Continuous Delivery and I had my share of DevOps stuff 2
  3. 3. #1 Enterprises are about to adopt DevOps and Continuous Delivery Eberhard Wolff - @ewolff
  4. 4. It’s ofcially a buzz word now Eberhard Wolff - @ewolff Lots of products in this space Advertisements etc 4
  5. 5. Eberhard Wolff - @ewolff Lots of DevOps and Continuous Delivery In Karlsruhe (not Berlin) Audience were “traditional” German companies Quickly sold out 5
  6. 6. Eberhard Wolff - @ewolff W-JAX – Java / Enterprise Conference Continuous Delivery track was in the largest room at the conference Significant change from JAX 2013 – just half a year ago 6
  7. 7. #2 Enterprises are di#erent Eberhard Wolff - @ewolff DevOps and Continuous Delivery were established in Startups …or at least the web business So they solve problems typically encountered there But enterprises are different 7
  8. 8. My IT is more complex than Amazon! Eberhard Wolff - @ewolff Some enterprises say their issues by nature are more complex than everybody else’s Even Amazon’s That is a bold statement Often this is an excuse not use approaches such as DevOps or Continuous Delivery Because they cannot possible work for them This might even be true – because Amazon has been using this approach for quite a number of years. So Amazon’s systems are adapted to DevOps and Continuous Delivery While most enterprise systems are not 8
  9. 9. Dev – features Ops – cost Eberhard Wolff - @ewolff Dev and Ops are not just separate They are even driven by different objectives These different objectives are a very basic assumption in enterprises To some extend it is true: - Ops for desktop PCs should be cost efficient – that is all that matters - Dev should of course be concerned with features So how do you get Dev and Ops to join? How do you get Ops people to even join a project then? It won’t help them to save costs. 9
  10. 10. Dev builds it Ops runs it Eberhard Wolff - @ewolff There is a barrier between those two divisions So usually you end up in this situation 10
  11. 11. You build it you run it Eberhard Wolff - @ewolff This is one of the cores of DevOps But it is very alien to enterprise organizations Shared responsiblities 11
  12. 12. #3 DevOps = organization Eberhard Wolff - @ewolff
  13. 13. Need to change the organization Eberhard Wolff - @ewolff Dev and Ops people need to collaborate Ideally Dev and Ops are in the same team This means you have to change the organization b/c you need teams for certain functions 13
  14. 14. Changing the organization is hard Eberhard Wolff - @ewolff People have all kinds of issues - Fear of losing their jobs - Fear of losing privileges - General unease about any changes So implementing DevOps in an organization is hard 14
  15. 15. DevOps = Culture Eberhard Wolff - @ewolff At the end DevOps is about collaboration So it is “just” a culture So a new organization is not necessarily needed 15
  16. 16. Do you need change the organization? Eberhard Wolff - @ewolff There are different ways to deals with this problem - Colocate team consisting of Dev and Ops At the end matrix organizations where line management and project are two different issues are quite common Separation might be needed because of regulations and Common goal still needed? Shared pain 16
  17. 17. DevOps teams Eberhard Wolff - @ewolff How can you get started? I believe a team that pioneers the approach for its application is not a bad idea This is not creating another silo – it is eliminating the silo for one specific project 17
  18. 18. #4 Time-toMarket is not that important Eberhard Wolff - @ewolff Startups cannot succeed if they are unable to put new features in the face of the customers quickly Enterprises are different They do just a few releases for a reason - The market is not that competitive - Other parts of the organization cannot keep up (e.g. training) Enterprises are doing just one release a quarter or so for a reason. It is not entirely obvious that releasing more frequent is always needed. However, releases and feature can be decoupled – so it is not always necessary to train the user or even introduce new features. 18
  19. 19. Sometimes time-tomarket is paramount Eberhard Wolff - @ewolff As soon as enterprises compete against other companies on the web they switch over other principles I know several examples from my own experience But those cases are not that interesting to me - because they are not fundamentally different to established approaches 19
  20. 20. Enterprises can also deploy quickly Eberhard Wolff - @ewolff If it is really necessary – an Enterprise can roll out a change in a matter of minutes As a quick fix It is just without any tests And without sophistication So the value must be somewhere else 20
  21. 21. #5 Benefts in the Enterprise are di#erent Eberhard Wolff - @ewolff So – if time to market is not always a good motivation to adopt DevOps and Continuous Delivery - why would enterprises care? 21
  22. 22. Automation = Reproducible = Reduced Risk Eberhard Wolff - @ewolff The Automation Continuous Delivery advocates means that the delivery process can be reproduced. So risk can be reduced – you are just doing the same thing over and over again. No more high risk releases on weekends No more “point of no return” Reducing risk appeals to entperises 22
  23. 23. Small batches = Reduced risk Eberhard Wolff - @ewolff Continuous Delivery at its core reduces the amount of code that is put into production at a release So the batch size is reduced This is essentially lean – smaller batches, less waste It reduces risk: In a smaller batch it is much less likely to introduce an error 23
  24. 24. Paradox: Enterprises’ Infrequent releases = Reduced risk Eberhard Wolff - @ewolff Why are enterprises releasing less often? This is a strategy to reduce risk A release might fail and it is hard to do. Therefore enterprises release less frequent. So there are just so many occasions when releases might fail So releasing more often seems risky to them But it is really a higher risk: Changes pile up and deployments are more likely to fail ----- Besprechungsnotizen (04.12.13 19:42) ----Quality = risk? 24
  25. 25. DevOps = customeroriented IT Eberhard Wolff - @ewolff The IT must still have separate organizational units They are not around Development or Operations So they are concerned with services and functions of the IT This has a lot benefits for enterprise ITs - A competitive advantage over external IT provider - Better service This might be a good reason to do DevOps in my experience 25
  26. 26. Test in Production Eberhard Wolff - @ewolff Using Feature Toggles allows you to test new features in production. Therefore the need for test environments is reduced. Having a production-like test environment is often not an option, anyway. A/B testing is also easily possible 26
  27. 27. #6 DevOps will be adopted like Agile Eberhard Wolff - @ewolff Agile and DevOps are about similar topics - Culture & values - Faster time to market 27
  28. 28. Step 1: Resistance Doubt Orthodox Bottom up Eberhard Wolff - @ewolff This is agile around 2000 When agile originally started it faced resistance People didn’t want to use it People thought it could not possibly work They were teaching the concepts in an orthodox ways – because otherwise people would not follow it Mostly technical people were introducing it It was not on the agenda of the management This is the state of DevOps and Continuous Delivery right now 28
  29. 29. Adoption: Orthodox Bottom up Eberhard Wolff - @ewolff This is agile around 2000 When agile originally started it faced resistance People didn’t want to use it People thought it could not possibly work They were teaching the concepts in an orthodox ways – because otherwise people would not follow it Mostly technical people were introducing it It was not on the agenda of the management This is the state of DevOps and Continuous Delivery right now 29
  30. 30. Problem: Buy-In from Management Eberhard Wolff - @ewolff
  31. 31. Step 2: Accepted in Mainstream Eberhard Wolff - @ewolff Most developers and technical managers agree this is the way to go No need to discuss the need for it any more Project start implementing it en masse This is Agile after 2005 31
  32. 32. Adoption: Just get a Coach Eberhard Wolff - @ewolff There are many coaches – and you just have them implement the technique for you 32
  33. 33. Problem: Hard to actually make it work Eberhard Wolff - @ewolff But it is still hard to really make agile work. There are too many 33
  34. 34. Step 3: Everybody claims he is doing it Eberhard Wolff - @ewolff Scrum has replaced Waterfall as a the defauilt This is the current situation 34
  35. 35. Problem: Core values are often not understood Eberhard Wolff - @ewolff The agile core values are often still not followed and understood. Sometime they are not even shared by the organization. Agile fits only specific organizations 35
  36. 36. Disillusion Eberhard Wolff - @ewolff It is obvious now that Agility won’t solve all problems 36
  37. 37. How can DevOps and Continuous Delivery avoid this? Eberhard Wolff - @ewolff
  38. 38. Customize Continuous Delivery & DevOps for Enterprises Eberhard Wolff - @ewolff The real problem are values and the environment agility is used in 38
  39. 39. #1 Enterprises are about to adopt DevOps and Continuous Delivery #2 Enterprises are different #3 DevOps=organization #4 Time-to-Market is not that important #5 Benefits in the Enterprise are different #6 DevOps will be adopted like Agile Eberhard Wolff - @ewolff
  40. 40. Thanks! Eberhard Wolff - @ewolff ----- Besprechungsnotizen (04.12.13 20:21) ----Incremental bringing it in show value 40

×