rational user group - may 2014 stockholm - devops from an ea perspective
DESCRIPTION
How could DevOps help major corporations break out of the legacy problem? Why is rapid deployment needed to go for an agile delivery?TRANSCRIPT
Rational User Group
2014-05-06
Joakim LindbomPrincipal | Enterprise Architect
Today’s themes- Why do you need DevOps?- Squish’m bugs early!- Why do you need to deploy 10
times/day?
Now, what’s this?
Speed Kills!
Speed Kills!
20012002
20032004
20052006
20072008
20092010
20112012
20132014
20152016
0
10
20
30
40
50
60
70
80
90
100
Best & BeautifulA IncB IncC Inc
Lack of speed kills!
The amount of caos increases
by itself
Termodynamics
2:a main law
DevOps is about increasing your responsiveness to customers
Devs New features
Ops Uptime, uptime & uptime
But – whatif Devs were meassured on uptime & Ops on new features? Just a thought….
Squish’m bugs early!
Why? Because Early = Cheap
Reqs
Specify system
Build SWDesign system
Write code
Build system
Install system
TestReqs
TestSpecs
Integr. test
Test design
Unit test
System test
UAT
Design-Build-Run approachA bit too waterfallish
Reqs
Specify system
Build SWDesign system
Write code
Build system
Install system
TestReqs
TestSpecs
Integr. test
Test design
Unit test
System test
UAT
Design-Build-Run approachA bit too waterfallish
Ops get involved
Add re
qs
Cloud = access to abundance
Cloud = access to abundance
You can have as many development, test & staging environments as you like!
But you cannot handle this manually!
http://www.capgemini.com/resources/world-quality-report-2013-14
Zero-Day foreverYour time to react on errors will approach ZERO
Will become reality with the growing mobile market and IoT.
Big IT Slow IT(not slow as in slow food….)
CEO/ President/ Managing Director
C-Level executives and board members
Managers Staff
3% 2% 3% 3%
12%10% 8% 8%
39%
33%
25%22%
36%42% 43%
46%
12%15%
22% 23%
Very Fast Fast About right Slow Very Slow
How slow is slow?OFF THE PACEThe pace of digital transformation is too slow – unless you’re the CEO.
Who are these guys?!?
MIT Center for Digital Business and Capgemini Consulting
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 LandscapeReport 2014
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 LandscapeReport 2014
The ability to innovate
is strictly coupled with
the ability to fail fast
Ten Observations on IT Complexity1. 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.10. Existing management approaches ignore complexity.
But what is SimpleIT?1. Non complex2. Small building blocks3. Autonomous4. They “know nothing”5. Service based6. Dynamic7. Like lego bricks8. Expose an OpenAPI10. Connect development and operations
But what is SimpleIT?
SimplifiedModularisedOptimisedHardened
Autonomous system?
Totally separate partsSeparate lifecycle!
Loose coupling paw rihk-titt
System
Stuff Data
Autonomous system?
We used to look at it from a technical boundaries perspective
System
Stuff Data
DevsArchitect Ops
Autonomous system?
But in order to unsure agilit, we need to include the people in the system definition
System
Stuff Data
DevsArchitect OpsOpenAPI
Autonomous system?
OpenAPI mindset = not a solution design for a specific purpose/project. Open for Innovation
~Autonomous system?
Release = just a mountain to climb…
Basics, get things in orderAd-hoc deployment
Structured & planned releases
Major event
Major RISKMajor hurdle
Climbing a Release-mountain, how many people experience it…
Industrialisation of ITIT development more and more viewed as "manufacturing"
Square boxes, repeat over and over
IT is innovationMistake!
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?
Deploy 10 time per dayHow will that help you?
Deploy oftenShorten feedback-loopBring back passion – show visible result earlyAllow (small) failuresAllow experimentationFollow Moore’s lawLearn by doing
But deploying often doesn’t mandate deploying to production equally often!
Deploy oftenBasis for Continuous ImprovementSlow break-down into µServicesGradual transition towards smaller building blocks
Continous improvement
Continuous rebuilding
Always. Even if “not needed”
Summing upDevOps – increase responsiveness
Lack of speed kills
Simplify, make smaller & rebuild – to fight complexity
Big kills!
Contact
JoakimLindbomPrincipal | Enterprise Architect
08-5368 39340708-166404
twitter: JoakimLindbom
http://www.slideshare.net/JoakimLindbomhttp://www.linkedin.com/in/joakimlindbom
Insert contact picture
Image sources, marked as OK to use commercially
https://upload.wikimedia.org/wikipedia/commons/8/8b/Buck_Mountain_Grand_Teton_NP1.jpghttps://upload.wikimedia.org/wikipedia/commons/d/de/Eisklettern_kl_engstligenfall.jpghttps://c1.staticflickr.com/1/1/1118807_a751d65ba5_z.jpg?zz=1https://upload.wikimedia.org/wikipedia/commons/4/4f/Eternal_clock.jpghttps://c1.staticflickr.com/9/8062/8189938256_2a683d2334_z.jpghttps://upload.wikimedia.org/wikipedia/commons/8/85/Git_branches_example.pnghttps://upload.wikimedia.org/wikipedia/commons/9/99/Highway_at_night_slow_shutter_speed_photography_02.jpghttps://c2.staticflickr.com/6/5058/5490790304_dc3d7c2b91_z.jpg