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
PRO

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 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 Slide

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

    View Slide

  4. “HERESY!”

    View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. RELIABLE
    REPEATABLE
    RAPID
    RECURRING

    View Slide

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

    View Slide

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

    View Slide

  11. View Slide

  12. 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 Slide

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

    View Slide

  14. 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 Slide

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

    View Slide

  16. View Slide

  17. RELIABLE
    REPEATABLE
    RAPID
    RECURRING

    View Slide

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

    View Slide

  19. LOAD BALANCING
    HIGH AVAILABILITY
    SCALING
    ELASTIC ARCHITECTURES
    RAPID RECOVERY

    View Slide

  20. 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 Slide