Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How build and deployment should shape software architectures

How build and deployment should shape software architectures

Build and deployment concerns can help us to avoid some architecture anti-patterns, and enable some useful system properties.

Matthew Skelton

September 10, 2012
Tweet

More Decks by Matthew Skelton

Other Decks in Technology

Transcript

  1. How build and deployment
    should shape software
    architectures
    Matthew Skelton CEng | thetrainline.com
    IASA UK Ignite 2, London | #iasaignite
    10 September 2012

    View full-size slide

  2. Systems engineering
    (robotics, control theory, sensors, neuroscience)
    Software
    development
    (finance, insurance, travel, pharma, media, medical imaging)
    now
    Build & Deployment
    at thetrainline.com
    @matthewpskelton

    View full-size slide

  3. architecture
    = f (build & deploy)
    (for some systems)

    View full-size slide

  4. “HERESY!”

    View full-size slide

  5. RELIABLE
    REPEATABLE
    RAPID
    RECURRING

    View full-size slide

  6. Web-based
    Frequently-
    changing
    Public-facing
    High-volume

    View full-size slide

  7. ‘R-R-R-R’
    BUILD AND DEPLOYMENT
    Helps to avoid the Ball of Mud

    View full-size slide

  8. BUILDABLE
    Small pipelined builds on generic build machines
    Seconds, not minutes or hours
    Short feedback cycles
    (Dan Worthington-Bodart, @danielbodart - http://bit.ly/M85wsX)

    View full-size slide

  9. TESTABLE
    Test (separation, harnesses, points)
    IDENTIFIABLE
    Meaningful versions, packages,
    defined dependencies, artefact
    management
    (think component boundaries)

    View full-size slide

  10. DEPLOYABLE
    Rapid, scriptable, simple failure modes
    MONITORABLE
    Logging, metrics, transaction tracing
    CONFIGURABLE
    Inject settings – no ‘black boxes’
    LIGHTWEIGHT
    Keep things small and easily comprehendible

    View full-size slide

  11. INSTANTIABLE
    No snowflakes or singletons
    RECOVERABLE
    No nasty zombies after failures
    MTTR more important than MTBF*
    * for most kinds of F

    View full-size slide

  12. RELIABLE
    REPEATABLE
    RAPID
    RECURRING

    View full-size slide

  13. Lightweight, Testable,
    Monitorable,
    Configurable,
    Recoverable, Identifiable
    component architecture

    View full-size slide

  14. LOAD BALANCING
    HIGH AVAILABILITY
    SCALING
    ELASTIC ARCHITECTURES
    RAPID RECOVERY

    View full-size slide

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

    View full-size slide