How build and deployment should shape software

architectures

Matthew Skelton CEng | thetrainline.com

IASA UK Ignite 2, London | #iasaignite

10 September 2012

Systems engineering(robotics, control theory, sensors, neuroscience)

Software development

(finance, insurance, travel, pharma, media, medical imaging)

now

Build & Deployment at thetrainline.com

@matthewpskelton

architecture

= f (build & deploy)(for some systems)

“HERESY!”

RELIABLE

REPEATABLE

RAPID

RECURRING

Web-based

Frequently-changing

Public-facing

High-volume

‘R-R-R-R’ BUILD AND DEPLOYMENT

Helps to avoid the Ball of Mud

BUILDABLE

Small pipelined builds on generic build machines

Seconds, not minutes or hours

Short feedback cycles(Dan Worthington-Bodart, @danielbodart - http://bit.ly/M85wsX)

TESTABLE

Test (separation, harnesses, points)

IDENTIFIABLE

Meaningful versions, packages, defined dependencies, artefact

management

(think component boundaries)

DEPLOYABLERapid, scriptable, simple failure modes

MONITORABLELogging, metrics, transaction tracing

CONFIGURABLEInject settings – no ‘black boxes’

LIGHTWEIGHTKeep things small and easily comprehendible

INSTANTIABLE

No snowflakes or singletons

RECOVERABLE

No nasty zombies after failures

MTTR more important than MTBF** for most kinds of F

RELIABLE

REPEATABLE

RAPID

RECURRING

Lightweight, Testable, Monitorable, Configurable,

Recoverable, Identifiablecomponent architecture

LOAD BALANCINGHIGH AVAILABILITY

SCALINGELASTIC ARCHITECTURES

RAPID RECOVERY

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