2015 10 dev ops n-fi - why it's a good idea to deploy 10 times per day v1.0 - external
49
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
-
Upload
joakim-lindbom -
Category
Technology
-
view
81 -
download
0
Transcript of 2015 10 dev ops n-fi - why it's a good idea to deploy 10 times per day v1.0 - external
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
Now, what’s this?
Speed Kills!
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!
Zero-Day forever
Your time to react on errors will approach ZERO
Will become reality with the ever growing mobile market and IoT.
Zero-Day forever
Your time to react on errors will approach ZERO
Will become reality with the ever growing mobile market and IoT.
The amount of caos increases
by itself
Termodynamics
Second main law
Design-Build-Run
Conway’s Law
Reqs
Specify system
Build SWDesign system
Write code
Build system
Install system
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
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
http://www.capgemini.com/resources/world-quality-report-2013-14
https://www.worldqualityreport.com
You can have as many development, test & staging environments as you like!
But you cannot handle this manually!
Cloud = access to abundance
You can have as many development, test & staging environments as you like!
But you cannot handle this manually!
Cloud = access to abundance
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 andboard members
Managers Staff
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
Big IT Slow IT(not slow as in slow food….)
“The goal is to have more control over the system than it has over you.”
DevOps
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
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
The ability to innovate
is strictly coupled with
the ability to fail fast
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.
But what is Simple-IT, then?
1. Non complex2. Small building blocks3. Autonomous4. They “know nothing”5. Service based6. Dynamic7. Like lego bricks8. Pace layered - exposes an OpenAPI9. Joint development and operations
Knowing nothing?Image: Daily Mail
A.k.a.
Agile Architecture
DevOps is about increasing your responsiveness to customers
Devs New features, fast!
Ops Uptime, uptime & uptime
Devs Uptime
Ops New features, fast!
But whatif…
…should it be one joint team per system/service?
Or….
Autonomous system?
Totally separate parts
Separate lifecycle!
Loose coupling paw rihk-titt
System
Do stuff Data
Autonomous system?
We used to look at it from a technical boundaries perspective
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
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
~Autonomous system?
Release = just a mountain to climb…
Basics, get things in order
Ad-hoc deployment
Structured & planned releases
Major event
Major RISKMajor hurdle
Climbing a Release-mountain, how many people experience it…
Industrialisation of IT
IT development more and more viewed as "manufacturing"
Square boxes, repeat over and over
IT is about innovation
Mistake!
Deploy 10 time per dayHow will that help you?
Deploy often
Shorten feedback-loopBring back passion – show visible result earlyAllow (small) failuresAllow experimentationFollow Moore’s lawLearn by doing
But you don’t need to deploy to production10 times per day…
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
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?
Continous improvement
Continuous rebuilding
Always. Even if “not needed”
Example
Build chain
Does it compile
?
Unit tests OK?
SW quality metrics
Build Deploy
trunc
Check-in
Auto
Test
Build chain
Does it compile
?
Unit tests OK?
SW quality metrics
Build Deploy
trunc
Check-in
Manual
trigger
Production
Dev-test
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/
Summing up
Lack of speed kills
DevOps – increase responsiveness
Simplify, make smaller & rebuild – to fight complexity
Automate to avoid simple misstakes!
Contact
JoakimLindbomPrincipal | Enterprise Architect
08-5368 39340708-166404
twitter: JoakimLindbom
http://www.slideshare.net/JoakimLindbomhttp://www.linkedin.com/in/joakimlindbom
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
