How build and deployment
should shape software
architectures
Matthew Skelton CEng | thetrainline.com
IASA UK Ignite 2, London | #iasaignite
10 September 2012
Slide 2
Slide 2 text
Systems engineering
(robotics, control theory, sensors, neuroscience)
Software
development
(finance, insurance, travel, pharma, media, medical imaging)
now
Build & Deployment
at thetrainline.com
@matthewpskelton
Slide 3
Slide 3 text
architecture
= f (build & deploy)
(for some systems)
‘R-R-R-R’
BUILD AND DEPLOYMENT
Helps to avoid the Ball of Mud
Slide 11
Slide 11 text
No content
Slide 12
Slide 12 text
BUILDABLE
Small pipelined builds on generic build machines
Seconds, not minutes or hours
Short feedback cycles
(Dan Worthington-Bodart, @danielbodart - http://bit.ly/M85wsX)
Slide 13
Slide 13 text
TESTABLE
Test (separation, harnesses, points)
IDENTIFIABLE
Meaningful versions, packages,
defined dependencies, artefact
management
(think component boundaries)
Slide 14
Slide 14 text
DEPLOYABLE
Rapid, scriptable, simple failure modes
MONITORABLE
Logging, metrics, transaction tracing
CONFIGURABLE
Inject settings – no ‘black boxes’
LIGHTWEIGHT
Keep things small and easily comprehendible
Slide 15
Slide 15 text
INSTANTIABLE
No snowflakes or singletons
RECOVERABLE
No nasty zombies after failures
MTTR more important than MTBF*
* for most kinds of F
LOAD BALANCING
HIGH AVAILABILITY
SCALING
ELASTIC ARCHITECTURES
RAPID RECOVERY
Slide 20
Slide 20 text
architecture
= f (build & deploy)
(for some systems)
thank you
IASA: www.iasaglobal.org
matthewskelton.net | @matthewpskelton
Thanks to: Attila S, Jack R and Owain P for feedback.
Picture credits:
Petra: Wikimedia/Berthold Werner; army engineers: US DoD; ball of mud: pwern.blogspot.co.uk; sports car: xarj.net; zombie: bjj.org; feather:
Wikipedia; punch: thelegalblitz.com; passport: coverpalace.com; dogs: reluctantmemsahib.wordpress.com; Meccano: dalefield.com