How to break apart a monolithic system safely without destroying your team - Velocity 2016 - Matthew Skelton

Slide 1

Slide 1 text

How to break apart a monolithic system safely without destroying your team Matthew Skelton, Skelton Thatcher Consulting @matthewpskelton 07 November 2016, Amsterdam, NL - #velocityconf

Slide 2

Slide 2 text

Today Cognitive load for teams ‘Monolith’ Code Forensics Team-first boundaries Monolith-splitting recipe

Slide 3

Slide 3 text

For now, let’s forget: Microservices CQRS / Event Sourcing Queues (Architectural changes)

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

Team-first digital transformation 30+ organisations UK, US, EU, India, China

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

How to break apart a monolithic system safely without destroying your team

Slide 8

Slide 8 text

Safer, more rapid changes to software systems (Business Agility)

Slide 9

Slide 9 text

A ‘team-first’ approach to software subsystem boundaries

Slide 10

Slide 10 text

TEAM

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

TEAM capabilities appetite & aptitude understanding responsibilities

Slide 13

Slide 13 text

(assumption) the team is stable, slowly changing, and long-lived #NoProjects

Slide 14

Slide 14 text

Conway’s Law

Slide 15

Slide 15 text

“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” – Mel Conway, 1968 http://www.melconway.com/Home/Conways_Law.html

Slide 16

Slide 16 text

Front-end developers Back-end developers

Slide 17

Slide 17 text

‘Reverse Conway’ Tobbe Gyllebring (@drunkcod)

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

homomorphic force (#Conway  #Yawnoc) HT @allankellynet (same) (shape)

Slide 20

Slide 20 text

Cognitive load for teams

Slide 21

Slide 21 text

Cognitive load the total amount of mental effort being used in the working memory (see Sweller, 1988)

Slide 22

Slide 22 text

Cognitive load Intrinsic Extraneous (Irrelevant ) Germane (Relevant)

Slide 23

Slide 23 text

‘Hacking Your Head’: Jo Pearce See http://www.slideshare.net/JoPearce5/hacking-your-head-managing-information-overload-45-mix @jdpearce

Slide 24

Slide 24 text

We have SCIENCE!

Slide 25

Slide 25 text

Science since 1988 (!) • Driskell et al, 1999 ‘Does Stress Lead to a Loss of Team Perspective?’ Group Dynamics: Theory, Research, and Practice 3, no. 4 (1999): 291. • Fan et al, 2010 ‘Learning HMM-Based Cognitive Load Models for Supporting Human-Agent Teamwork’. Cognitive Systems Research 11, no. 1 (2010): 108–119. • Ilgen & Hollenbeck, 1993 ‘Effective Team Performance under Stress and Normal Conditions: An Experimental Paradigm, Theory and Data for Studying Team Decision Making in Hierarchical Teams with Distributed Expertise’. DTIC Document, 1993. • Johnston et al, 2002 ‘Application of Cognitive Load Theory to Developing a Measure of Team Decision Efficiency’. DTIC Document, 2002. • Sweller, John, 1994 ‘Cognitive Load Theory, Learning Difficulty, and Instructional Design’. Learning and Instruction 4 (1994): 295–312. • Sweller, John, 1988. ‘Cognitive Load during Problem Solving: Effects on Learning’. Cognitive Science 12, no. 2 (1988): 257–285.

Slide 26

Slide 26 text

“stress impacts team performance … by narrowing or weakening the team-level perspective required for effective team behavior.” – Driskell et al, 1999 Group Dynamics: Theory, Research, and Practice 1999, Vol. 3, No. 4,291-302

Slide 27

Slide 27 text

(not just ‘pop’ science!)

Slide 28

Slide 28 text

‘Monolith’

Slide 29

Slide 29 text

monolith μόνο λίθος “single stone” Reiner Flassig - CC BY-SA 2.0 de - Wikipedia

Slide 30

Slide 30 text

“Don’t start with a monolith when your goal is a microservices architecture” – Stefan Tilkov, innoQ http://martinfowler.com/articles/dont-start-monolith.html

Slide 31

Slide 31 text

“Start monolithic and extract” – Tammer Saleh, Pivotal https://www.infoq.com/presentations/cloud-anti-patterns

Slide 32

Slide 32 text

A ‘team-first’ approach to software subsystem boundaries

Slide 33

Slide 33 text

Types of software monoliths •Application monolith •Joined at the DB •Monolithic build (rebuild everything) •Monolithic releases (coupled) •Monolithic thinking (standardisation)

Slide 34

Slide 34 text

Application monolith Single block of code Deployed as a unit

Slide 35

Slide 35 text

Joined at the DB Difficult to change separately (but not impossible) Risk is (probably) elevated Chris Collyer, http://www.stone-circles.org.uk/stone/pentreifan.htm

Slide 36

Slide 36 text

Monolithic builds One gigantic CI build just to get a new version of any component

Slide 37

Slide 37 text

Monolithic releases Smaller components bundled together into a ‘release’

Slide 38

Slide 38 text

Monolithic thinking ‘One-size-fits-all’ for teams Assumption that minimising variation is A Good Thing

Slide 39

Slide 39 text

Dangers of splitting a monolith •Reduced domain consistency •Data duplication (unintentional) •Additional operational complexity due to distributed system and async messaging •Degraded UX across the product

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

Splitting a monolith Reiner Flassig - CC BY-SA 2.0 de - Wikipedia Choose the right technique for splitting Understand the nature of the monolith

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

‘Fracture planes’ for code •Business domain bounded context •Regulatory compliance •Change cadence •Risk •Performance isolation •User personas •Team location

Slide 46

Slide 46 text

‘Fracture planes’ for code Ask: Could we consume this thing as a service?

Slide 47

Slide 47 text

‘Fracture planes’ for code Ask: Could we provide this thing as a service?

Slide 48

Slide 48 text

Code Forensics

Slide 49

Slide 49 text

Forensics Your Code as a Crime Scene Adam Tornhill

Slide 50

Slide 50 text

Adam Tornhill Code, Crime, Complexity: Analyzing software with forensic psychology Adam Tornhill TEDxTrondheim youtube.com/watch?v=qJ_hplxTYJw

Slide 51

Slide 51 text

‘Code Maat’ tool

Slide 52

Slide 52 text

Adam Tornhill, http://www.adamtornhill.com/articles/crimescene/codeascrimescene.htm Code City plus Code Maat forensics

Slide 53

Slide 53 text

Beware of badly-named subsystems

Slide 54

Slide 54 text

"information-poor abstract names are magnets for extra [unwanted] responsibilities" – Adam Tornhill p.185, Your Code as a Crime Scene

Slide 55

Slide 55 text

Team-first boundaries

Slide 56

Slide 56 text

DevOpsTopologies.com

Slide 57

Slide 57 text

Team types Component team Platform / ’substrate’ team Supporting / ‘productivity’ team Product/Feature team

Slide 58

Slide 58 text

Team types devopstopologies.com Platform / ’substrate’ team Product/Feature team

Slide 59

Slide 59 text

Team types devopstopologies.com Component team Platform / ’substrate’ team Product/Feature team

Slide 60

Slide 60 text

Team types devopstopologies.com Component team Platform / ’substrate’ team Product/Feature team Supporting / ‘productivity’ team

Slide 61

Slide 61 text

Code repositories Align repositories to subsystem boundaries Avoid monolithic-y repos like TFS* * Don’t get me started on TFS, grrr…

Slide 62

Slide 62 text

Code repositories Repo 1 Build Test Deploy Run Repo 2 Build Test Deploy Run Repo 3 Build Test Deploy Run

Slide 63

Slide 63 text

“You can use a monorepo only if your organisation has published a scientific paper on Computer Science. Otherwise, use one repo per deployable runnable thing.” – Matthew Skelton LondonCD meetup group, 11 Oct 2016 

Slide 64

Slide 64 text

Find natural or available ‘fracture planes’ for splitting a monolith (with the team in mind)

Slide 65

Slide 65 text

Industry experience Examples from recent work with clients Different monoliths Different ‘fracture planes’

Slide 66

Slide 66 text

Software for R&D teams Customers: over 80% of top 20 global pharma companies

Slide 67

Slide 67 text

2014: Monolithic: builds, releases Pharma GxP: traceability Changes slow and tricky

Slide 68

Slide 68 text

Fracture plane: business domain

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

Fracture plane: technology

Slide 72

Slide 72 text

Compose with packages Logging for insights Technology splits Improved traceability

Slide 73

Slide 73 text

Major UK broadcaster (TV + online) Increasing digital delivery of content

Slide 74

Slide 74 text

2014: Wide mix of technologies Need for visibility of changes Need for rapid turnaround

Slide 75

Slide 75 text

Fracture planes: read-only, location & cadence

Slide 76

Slide 76 text

Split off Reporting (read-only) Split on change cadence Increased change throughput

Slide 77

Slide 77 text

UK’s second largest credit reference agency Customers: major banks + large orgs

Slide 78

Slide 78 text

2014: 6-weekly monolithic release Outage-sensitive customers

Slide 79

Slide 79 text

Fracture planes: risk & business domain

Slide 80

Slide 80 text

Split releases based on risk Align teams to value streams More rapid release cadence

Slide 81

Slide 81 text

Software for Internal Comms Customers: FTSE 100 & Fortune 1000

Slide 82

Slide 82 text

2015: Successful system (monolithic) ISO 27001 compliance Aim to expand the org (x N)

Slide 83

Slide 83 text

Fracture plane: business domain

Slide 84

Slide 84 text

Optimise split for team engagement & personas Minimise ISO 27001 footprint Aided organisation expansion

Slide 85

Slide 85 text

When not to split a monolith •‘Heritage’ ERP system (‘cloudified’) •No native Unit Test framework •20-30 min startup times •VMs need 56GB RAM (yes) •CI builds take 50 mins

Slide 86

Slide 86 text

Monolith-splitting recipe Tried and tested!

Slide 87

Slide 87 text

Monolith-splitting recipe 1. Instrument the monolith – logging 2. Grok data flows and fault responses 3. Align teams to available segments 4. Split off segments one-by-one

Slide 88

Slide 88 text

Instrument the monolith

Slide 89

Slide 89 text

Instrument the monolith

Slide 90

Slide 90 text

Instrument the monolith

Slide 91

Slide 91 text

search by event Event ID {Delivered, InTransit, Arrived}

Slide 92

Slide 92 text

transaction trace Correlation ID 612999958…

Slide 93

Slide 93 text

Technical Domain public enum EventID { // Badly-initialised logging data NotSet = 0, // An unrecognised event has occurred UnexpectedError = 10000, ApplicationStarted = 20000, ApplicationShutdownNoticeReceived = 20001, PageGenerationStarted = 30000, PageGenerationCompleted = 30001, MessageQueued = 40000, MessagePeeked = 40001, BasketItemAdded = 60001, BasketItemRemoved = 60002, CreditCardDetailsSubmitted = 70001, // ... }

Slide 94

Slide 94 text

BasketItemAdded = 60001 BasketItemRemoved = 60002

Slide 95

Slide 95 text

Instrument the monolith Correlation ID Logs Event ID

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

use logging as a channel/vector to make distributed systems more testable use logging as a channel/vector to make distributed systems more testable

Slide 98

Slide 98 text

Grok data flows and fault responses

Slide 99

Slide 99 text

Grok data flows and fault responses Correlation ID Event ID Unexpected collaborating subsystems Undetected fault condition

Slide 100

Slide 100 text

Grok data flows and fault responses Correlation ID Event ID Adjust subsystem boundaries Fix poor fault responses

Slide 101

Slide 101 text

runbooktemplate.info Run Book dialogue sheets

Slide 102

Slide 102 text

Align teams to available segments

Slide 103

Slide 103 text

Align teams to available segments

Slide 104

Slide 104 text

Align teams to available segments Map to business domain

Slide 105

Slide 105 text

Align teams to available segments Identify likely components or ‘platform’ elements

Slide 106

Slide 106 text

Split off segments one-by-one

Slide 107

Slide 107 text

Split off segments one-by-one

Slide 108

Slide 108 text

Split off segments one-by-one Separate: - Builds - Infrastructure - Deployments - Versions - Lifecycle

Slide 109

Slide 109 text

Team needs / responsibilities / capabilities come first

Slide 110

Slide 110 text

use logging as a channel/vector to make distributed systems more testable Invest in Build & Release Engineering

Slide 111

Slide 111 text

No content

Slide 112

Slide 112 text

Monolith-splitting recipe * 1. Instrument the monolith – logging 2. Grok data flows and fault responses 3. Align teams to available segments 4. Split off segments one-by-one (5. Invest in Build & Release Engineering) * The simplistic version

Slide 113

Slide 113 text

Monolith-splitting recipe * 1. Instrument 2. Grok behaviour 3. Align teams 4. Split off segments 5. Invest in Build & Release * The simplistic version

Slide 114

Slide 114 text

Monolith-splitting recipe * * The simplistic version 1. Instrument 2. Grok behaviour 3. Align teams 4. Split off segments 5. Invest in Build & Release

Slide 115

Slide 115 text

Determine monolith type (Apply ‘Code Forensics’) Find ‘fracture planes’ Assess cognitive load for teams Use the monolith-splitting recipe How to break apart a monolithic system safely without destroying your team

Slide 116

Slide 116 text

Further material

Slide 117

Slide 117 text

No content

Slide 118

Slide 118 text

Books & articles • Working Effectively with Legacy Code, by Michael Feathers • Building Microservices by Sam Newman (O’Reilly, 2015) • Managing Cognitive Load for Team Learning by Jo Pearce http://12devsofxmas.co.uk/2015/12/day-3-managing-cognitive-load- for-team-learning/ • Continuous Delivery with Windows and .NET by Matthew Skelton and Chris O’Dell (O’Reilly, 2016) http://cdwithwindows.net/ • Team Guide to Software Operability by Matthew Skelton and Rob Thatcher (Skelton Thatcher Publications, 2016) http://operabilitybook.com/ • Ye Olde Monolith by Pter Pilgrim https://dzone.com/articles/ye-olde- monolith

Slide 119

Slide 119 text

Training • From Monolith to Microservices (online training) – Sam Newman, author of Building Microservices http://www.oreilly.com/live-training/from-monolith-to- microservices.html • Run Book template & Run Book dialogue sheets http://runbooktemplate.info/

Slide 120

Slide 120 text

Talks & slides • Hacking Your Head – Managing Information Overload, by Jo Pearce - http://www.slideshare.net/JoPearce5/hacking-your- head-managing-information-overload-45-mix / http://conferences.oreilly.com/oscon/open-source- eu/public/schedule/detail/53013 • Principles of Microservices by Sam Newman @ Devoxx 2015 https://www.youtube.com/watch?v=PFQnNFe27kU

Slide 121

Slide 121 text

Research papers • Driskell, James E., Eduardo Salas, and Joan Johnston. ‘Does Stress Lead to a Loss of Team Perspective?’ Group Dynamics: Theory, Research, and Practice 3, no. 4 (1999): 291. • Fan, Xiaocong, Po-Chun Chen, and John Yen. ‘Learning HMM-Based Cognitive Load Models for Supporting Human-Agent Teamwork’. Cognitive Systems Research 11, no. 1 (2010): 108–119. • Ilgen, Daniel R., and John R. Hollenbeck. ‘Effective Team Performance under Stress and Normal Conditions: An Experimental Paradigm, Theory and Data for Studying Team Decision Making in Hierarchical Teams with Distributed Expertise’. DTIC Document, 1993. http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA284683. • Johnston, Joan H., Stephen M. Fiore, Carol Paris, and C. A. Smith. ‘Application of Cognitive Load Theory to Developing a Measure of Team Decision Efficiency’. DTIC Document, 2002. http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA525820. • Sweller, John. ‘Cognitive Load Theory, Learning Difficulty, and Instructional Design’. Learning and Instruction 4 (1994): 295–312. • Sweller, John. ‘Cognitive Load during Problem Solving: Effects on Learning’. Cognitive Science 12, no. 2 (1988): 257–285.