DevOps: Some problems it can help you as on organisation to avoid, put in context with legacy problems, micro services and autonomous systems.

1. Why it’s a good idea
to deploy 10 times per day
2015-01-20
Joakim Lindbom
Principal | Enterprise Architect
http://www.slideshare.net/JoakimLindbom

3. Now, what’s this?

4. Speed Kills!

5. 0
10
20
30
40
50
60
70
80
90
100
2001 2003 2005 2007 2009 2011 2013 2015
Best & Beautiful
A Inc
B Inc
C Inc
Lack of speed kills!

7. Zero-Day forever
Your time to react on errors will approach ZERO
Will become reality with the ever growing mobile market and IoT.

8. Zero-Day forever
Your time to react on errors will approach ZERO
Will become reality with the ever growing mobile market and IoT.

9. The amount of
caos increases
by itself
Termodynamics
Second main law

10. Design-Build-Run
Conway’s Law

11. Reqs
Specify
system
Build SW
Design
system
Write
code
Build
system
Install
system
Design-Build-Run approach
A bit too waterfallish

12. 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
Design-Build-Run approach
A bit too waterfallish

13. 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
Design-Build-Run approach
A bit too waterfallish

14. http://www.capgemini.com/resources/world-quality-report-2013-14

15. https://www.worldqualityreport.com

16. You can have as many development, test & staging
environments as you like!
But you cannot handle this manually!
Cloud = access to abundance

17. You can have as many development, test & staging
environments as you like!
But you cannot handle this manually!
Cloud = access to abundance

18. 3% 2% 3% 3%
12%
10% 8% 8%
39%
33%
25%
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
How slow is slow?OFF THE PACE
The pace of digital transformation is too slow – unless you’re the CEO.
Who are these
guys?!?
MIT Center for Digital Business and Capgemini Consulting

19. Big IT  Slow IT
(not slow as in slow food….)

20. “The goal is to have
more control over the
system than it has
over you.”
DevOps

21. 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

22. 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

23. The ability to innovate
is strictly coupled with
the ability to fail fast

24. 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.

25. 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. Pace layered - exposes an OpenAPI
9. Joint development and operations
Knowing
nothing?
Image: Daily Mail
A.k.a.
Agile Architecture

26. DevOps is about increasing your
responsiveness to customers

27. Devs  New features, fast!
Ops  Uptime, uptime & uptime

28. Devs  Uptime
Ops  New features, fast!
But whatif…

29. …should it be one joint team per system/service?
Or….

30. Autonomous system?
Totally separate parts
Separate lifecycle!
Loose coupling paw rihk-titt

31. System
Do stuff Data
Autonomous system?
We used to look at it from a technical boundaries
perspective

32. System
Do stuff Data
DevArchitect Test
Autonomous system?
But in order to ensure agility, we need to include
the people in the system definition
Ops

33. System
Do stuff Data
OpenAPI
Autonomous system?
OpenAPI mindset = not a solution design for a
specific purpose/project. Open for Innovation
DevArchitect TestOps
Open
Data
Lake

34. ~Autonomous system?
Release = just a mountain to climb…

35. Basics, get things in order
Ad-hoc deployment
Structured & planned releases
Major event
Major RISKMajor hurdle

36. Climbing a Release-mountain, how many people
experience it…

37. Industrialisation of IT
IT development more and more viewed as
"manufacturing"
Square boxes, repeat over and over
IT is about
innovation
Mistake!

38. Deploy 10 time per day
How will that help you?

39. 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…

40. Deploy often
Basis for Continuous Improvement
Slow break-down into µServices
Gradual transition towards smaller building
blocks
Läs mer: http://www.capgemini.com/blog/capping-it-
off/2015/01/devops-and-microservices-a-security-view

41. How good is good?
Compileable?
No warnings?
Runnable?
Passing tests?
Not breaking anything else?
When your developers check in code, how
good does it need to be?

42. Continous improvement
Continuous rebuilding
Always. Even if “not needed”

43. Example

44. Build chain
Does it
compile
?
Unit
tests
OK?
SW
quality
metrics
Build Deploy
trunc
Check-in
Auto
Test

45. Build chain
Does it
compile
?
Unit
tests
OK?
SW
quality
metrics
Build Deploy
trunc
Check-in
Manual
trigger
Production
Dev-test

46. Tools
Hudson/Jenkins – base automation
Phing – PHP specific manipulation tool
SonarQube – Software quality, general
PHPUnit + LoC, Copy/Paste Detector, Mess
Detector, et all
https://github.com/sebastianbergmannhttp://www.sonarqube.org/

47. Summing up
Lack of speed kills
DevOps – increase responsiveness
Simplify, make smaller & rebuild – to fight
complexity
Automate to avoid simple misstakes!

48. 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

49. 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