2014-10 DevOps NFi - Why it's a good idea to deploy 10 times per day v1.0
•Download as PPTX, PDF•
0 likes•2,345 views
Corporations are struggling with overly complex systems and system landscapes. DevOps is presented as one piece of the puzzle to go for much leaner and simpler landscapes - all in order to increase the readiness for change and innovation. The presentation also discusses the the basic thought error behind organising according to Design-Build-Run, which is the basis for most ICT IM outsourcing.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 2014-10 DevOps NFi - Why it's a good idea to deploy 10 times per day v1.0
Similar to 2014-10 DevOps NFi - Why it's a good idea to deploy 10 times per day v1.0 (20)
More from Joakim Lindbom
More from Joakim Lindbom (11)
Recently uploaded
Recently uploaded (20)
2014-10 DevOps NFi - Why it's a good idea to deploy 10 times per day v1.0
- 1. Why it’s a good idea to deploy 10 times per day 2014-10-08 Joakim Lindbom Principal | Enterprise Architect
- 4. Speed Kills!
- 5. 90 80 70 60 50 40 30 20 10 0 100 Lack of speed kills! 2001 2003 2005 2007 2009 2011 2013 2015 Best & Beautiful A Inc B Inc C Inc
- 7. Zero-Day forever Your time to react on errors will approach ZERO Will become reality with the growing mobile market and IoT.
- 8. Zero-Day forever Your time to react on errors will approach ZERO Will become reality with the growing mobile market and IoT.
- 9. Termodynamics Second main law The amount of caos increases by itself
- 10. Design-Build-Run
- 11. Design-Build-Run approach Reqs Specify system Build SW Design system Write code Build system Install system Test Reqs Test Specs Integr. test Test design Unit test System test UAT A bit too waterfallish
- 14. Cloud = access to abundance
- 15. Cloud = access to abundance You can have as many development, test & staging environments as you like! But you cannot handle this manually!
- 16. Big IT Slow IT (not slow as in slow food….)
- 17. OFF THE PACEHow slow is slow? The pace of digital transformation is too slow – unless you’re the CEO. 12% 33% 25% Who are these 10% 8% 8% 39% guys?!? 3% 2% 3% 3% 22% 36% 42% 43% 46% 12% 15% 22% 23% CEO/ President/ Managing Director C-Level executives and board members Managers Staff Very Fast Fast About right Slow Very Slow MIT Center for Digital Business and Capgemini Consulting
- 18. IT Legacy is #1 obstacle for innovation Major corporations depend on core systems that - Are 15-20 years old - 3-4 persons know - Some staff is retired, some will be it within 4-5 years - Technology support is slow - Are somewhat documented - Have few formal test cases, but the staff know how to test Application Landscape Report 2014
- 19. IT Legacy is #1 obstacle for innovation Major corporations depend on core systems that - Are 25-45 years old - 1-2 persons know - All staff are retired, or will be it within 2-3 years - Technology support is gone - Are undocumented - Have no/few formal test cases Application Landscape Report 2014
- 20. The ability to innovate is strictly coupled with the ability to fail fast
- 21. Nine observations on IT Complexity 1. Most IT systems are too complex. 2. "Best Practices" increase complexity. 3. Complex systems cost more to build. 4. Complex systems are harder to deliver. 5. Complex systems are less secure. 6. Complex systems are less reliable. 7. Complex systems are less agile. 8. Complex systems cost more to run. And 9. Existing management approaches ignore complexity.
- 22. But what is Simple-IT, then? 1. Non complex 2. Small building blocks 3. Autonomous 4. They “know nothing” 5. Service based 6. Dynamic 7. Like lego bricks 8. Exposes an OpenAPI 10. Joint development and operations Knowing nothing? Image: Daily Mail
- 23. But what is Simple-IT, then? Simplified Modularised Optimised Hardened
- 24. DevOps is about increasing your responsiveness to customers
- 25. Devs New features, fast! Ops Uptime, uptime & uptime
- 26. But whatif… Devs Uptime Ops New features, fast!
- 27. Or…. …should it be one joint team per system/service?
- 28. Autonomous system? Totally separate parts Separate lifecycle! Loose coupling paw rihk-titt
- 29. Autonomous system? Stuff Data System We used to look at it from a technical boundaries perspective
- 30. Autonomous system? Stuff Data Architect Dev Test System Ops But in order to ensure agility, we need to include the people in the system definition
- 31. Autonomous system? Stuff Data Architect Dev Ops Test System OpenAPI Open Data Lake OpenAPI mindset = not a solution design for a specific purpose/project. Open for Innovation
- 32. ~Autonomous system? Release = just a mountain to climb…
- 33. Basics, get things in order Ad-hoc deployment Structured & planned releases Major hurdle Major RISK Major event
- 34. Climbing a Release-mountain, how many people experience it…
- 35. Industrialisation of IT IT development more and more viewed as "manufacturing" Square boxes, repeat over and over Mistake! IT is innovation
- 36. How good is good? When your developers check in code, how good does it need to be? Compileable? No warnings? Runnable? Passing tests? Not breaking anything else?
- 37. Deploy 10 time per day How will that help you?
- 38. Deploy often Shorten feedback-loop Bring back passion – show visible result early Allow (small) failures Allow experimentation Follow Moore’s law Learn by doing But you don’t need to deploy to production 10 times per day…
- 39. Deploy often Basis for Continuous Improvement Slow break-down into μServices Gradual transition towards smaller building blocks
- 40. Continous improvement Continuous rebuilding Always. Even if “not needed”
- 41. Example
- 42. Build chain Does it compile ? Unit tests OK? SW quality metrics Build Deploy trunc Auto Check-in Test
- 43. Build chain Does it compile ? Unit tests OK? SW quality metrics Build Deploy trunc Manual Check-in Production Dev-test
- 44. Tools Hudson/Jenkins/Ant – base automation Phing – PHP specific manipulation tool SonarQube – Software quality, general PHPUnit + LoC, Copy/Paste Detector, Mess Detector, et all http://www.sonarqube.org/ https://github.com/sebastianbergmann
- 45. Summing up Lack of speed kills DevOps – increase responsiveness Simplify, make smaller & rebuild – to fight complexity Automate to avoid simple misstakes!
- 46. Contact Joakim Lindbom Principal | Enterprise Architect Joakim.Lindbom@capgemini.com 08-5368 3934 0708-166404 twitter: JoakimLindbom http://www.slideshare.net/JoakimLindbom http://www.linkedin.com/in/joakimlindbom
- 47. Image sources, marked as OK to use commercially https://upload.wikimedia.org/wikipedia/commons/8/8b/Buck_Mountain_Grand_Teton_NP1.jpg https://upload.wikimedia.org/wikipedia/commons/d/de/Eisklettern_kl_engstligenfall.jpg https://c1.staticflickr.com/1/1/1118807_a751d65ba5_z.jpg?zz=1 https://upload.wikimedia.org/wikipedia/commons/4/4f/Eternal_clock.jpg https://c1.staticflickr.com/9/8062/8189938256_2a683d2334_z.jpg https://upload.wikimedia.org/wikipedia/commons/8/85/Git_branches_example.png https://upload.wikimedia.org/wikipedia/commons/9/99/Highway_at_night_slow_shutter_speed_ph otography_02.jpg https://c2.staticflickr.com/6/5058/5490790304_dc3d7c2b91_z.jpg http://www.dailymail.co.uk/tvshowbiz/article-1176568/Andrew-Sachs-thanks-Jonathan-Ross- Russell-Brand-boosting-career.html https://upload.wikimedia.org/wikipedia/commons/8/8b/CERN_Server.jpg
Editor's Notes
- Tillbaka till själva grundidén – automatisera arbete, nu även för oss i IT-branschen… Ada Lovelace – program för Analytical Engine, Bernoulli-talserie, 1842
- (Computer in a RJ45 enclosure) Moore’s law – does your org follow it??!?
- Authority: CM not in order - can only go forward. Lots of dead code in production There are roughly 160 rooms, including 40 bedrooms, 2 ballrooms (one completed and one unfinished) as well as 47 fireplaces, over 10,000 panes of glass, 17 chimneys (with evidence of two others), two basements and three elevators Now 1.8 ha (bare minimum for the remaining buildings) Stairs with no end Doors ending in the façade at third floor Built without architecture – more or less totally unfunctional
- Immediate testing and patching will need to be extremely speedy, automated and invisible (to the end-user)
- October 2014
- William Thomson, 1st Baron Kelvin A system will always strive towards more chaos, unless energy is added in order to lower chaos. Second law: An isolated system, if not already in its state of thermodynamic equilibrium, spontaneously evolves towards it. Thermodynamic equilibrium has the greatest entropy amongst the states accessible to the system.
- Tankefel! Conway’s law – “organisation are constrained to produce designs which are copies of the communication structure of these organisations”
- Treath: Handle multiple environments incl. relevant test data
- You’ll always need one more environment
- You’ll always need one more environment
- Source: MITSloan Management Review – Research Report 2013 2013 Digital transformation global executive study and research project
- Swedbank Open-ended – Roulette “all in” vs. Poker
- Andrew Sachs - http://www.dailymail.co.uk/tvshowbiz/article-1176568/Andrew-Sachs-thanks-Jonathan-Ross-Russell-Brand-boosting-career.html Fair use
- Ops – will have to receive ”any crap” since Dev just want to rush it Devs – will have to wait until Ops feels they are ready
- Whatif Devs were meassured on uptime & Ops on new features? Just a thought….
- ”But we already outsourced ops and kept dev...”
- Netflix: Developers build, deploy and operate their own server clusters and are accountable when things go wrong
- Weeks of planning, people flown in, gather everybody 1 week
- Remember Winchester Mystery House? Horisaki – The object is not protected, the craftmen’s skills are. In order to keep knowledge Add new aspect area - Knowledge – to arch frameworks? If the architect doesn’t add this capability upfront, how can it be assured?