Slide 1

Slide 1 text

@[email protected] Enabling Microservice Success Sarah Wells

Slide 2

Slide 2 text

@[email protected] Enabling Microservice Success Sarah Wells

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

@[email protected] What does a successful software development organisation look like?

Slide 7

Slide 7 text

Slide 8

Slide 8 text

@[email protected] Accelerate defines performance in terms of the impact on the productivity, profitability and market share of your business, compared to competitors

Slide 9

Slide 9 text

@[email protected] Four outcomes that link to high performance: ● short lead time ● high deployment frequency ● low change fail percentage ● short mean time to restore

Slide 10

Slide 10 text

@[email protected] Accelerate's key capabilities (Forsgren, Humble, Kim)

Slide 11

Slide 11 text

@[email protected] ● Regularly delivering real business value

Slide 12

Slide 12 text

@[email protected] 1. Regularly delivering real business value 2. Adapting to change 3. Maintaining appropriate service levels 4. Spending most of your time on meaningful work 5. Not having to start again 6. Keeping risk to an acceptable level

Slide 13

Slide 13 text

@[email protected] Reasons to choose microservices

Slide 14

Slide 14 text

@[email protected] Microservices are a solution to an organisational problem

Slide 15

Slide 15 text

@[email protected] Reasons to use microservices ● Because loose coupling supports flow

Slide 16

Slide 16 text

@[email protected] Reasons to use microservices ● Because loose coupling supports flow ● For the developer experience

Slide 17

Slide 17 text

@[email protected] Reasons to use microservices ● Because loose coupling supports flow ● For the developer experience ● Aids compliance and security

Slide 18

Slide 18 text

@[email protected] Reasons to use microservices ● Because loose coupling supports flow ● For the developer experience ● Aids compliance and security ● Scaling only where needed

Slide 19

Slide 19 text

@[email protected] Reasons to use microservices ● Because loose coupling supports flow ● For the developer experience ● Aids compliance and security ● Scaling only where needed ● Increased robustness

Slide 20

Slide 20 text

@[email protected] Reasons to use microservices ● Because loose coupling supports flow ● For the developer experience ● Aids compliance and security ● Scaling only where needed ● Increased robustness ● Increased flexibility

Slide 21

Slide 21 text

Slide 22

Slide 22 text

@[email protected] Challenges

Slide 23

Slide 23 text

@[email protected] Challenges ● Estate complexity

Slide 24

Slide 24 text

@[email protected] Challenges ● Estate complexity ● Operational complexity

Slide 25

Slide 25 text

@[email protected] Challenges ● Estate complexity ● Operational complexity ● Finding the right granularity

Slide 26

Slide 26 text

@[email protected] Challenges ● Estate complexity ● Operational complexity ● Finding the right granularity ● Handling change

Slide 27

Slide 27 text

@[email protected] Challenges ● Estate complexity ● Operational complexity ● Finding the right granularity ● Handling change ● Developer experience is very different

Slide 28

Slide 28 text

@[email protected] Challenges ● Estate complexity ● Operational complexity ● Finding the right granularity ● Handling change ● Developer experience is very different ● Organisational change

Slide 29

Slide 29 text

@[email protected] Conditions for Success

Slide 30

Slide 30 text

@[email protected] Challenges ● Domain understanding

Slide 31

Slide 31 text

@[email protected] Challenges ● Domain understanding ● Products not projects

Slide 32

Slide 32 text

@[email protected] Challenges ● Domain understanding ● Products not projects ● Leadership support

Slide 33

Slide 33 text

@[email protected] Challenges ● Domain understanding ● Products not projects ● Leadership support ● Teams that want autonomy

Slide 34

Slide 34 text

@[email protected] Challenges ● Domain understanding ● Products not projects ● Leadership support ● Teams that want autonomy ● Support for that autonomy

Slide 35

Slide 35 text

@[email protected] Challenges ● Domain understanding ● Products not projects ● Leadership support ● Teams that want autonomy ● Support for that autonomy ● Technical maturity

Slide 36

Slide 36 text

@[email protected] 1. Regularly delivering real business value 2. Adapting to change 3. Maintaining appropriate service levels 4. Spending most of your time on meaningful work 5. Not having to start again 6. Keeping risk to an acceptable level

Slide 37

Slide 37 text

@[email protected] 1. Regularly delivering real business value

Slide 38

Slide 38 text

@[email protected] Four outcomes that link to high performance: ● short lead time ● high deployment frequency ● low change fail percentage ● short mean time to restore

Slide 39

Slide 39 text

Slide 40

Slide 40 text

@[email protected] Accelerate's key capabilities (Forsgren, Humble, Kim)

Slide 41

Slide 41 text

@[email protected] 2. Adapting to change

Slide 42

Slide 42 text

@[email protected] Changing business priorities

Slide 43

Slide 43 text

Slide 44

Slide 44 text

@[email protected] Changing technology

Slide 45

Slide 45 text

Slide 46

Slide 46 text

@[email protected] "For many years, the tongue-in-cheek definition of software architecture was “the stuff that’s hard to change later.” Later, the microservices architecture style appeared, where change is a first-class design consideration." From the preface of Fundamentals of Software Architecture, Mark Richards and Neal Ford

Slide 47

Slide 47 text

@[email protected] Beware the "long tail"

Slide 48

Slide 48 text

@[email protected] 3. Maintaining appropriate service levels

Slide 49

Slide 49 text

@[email protected] Four outcomes that link to high performance: ● short lead time ● high deployment frequency ● low change fail percentage ● short mean time to restore

Slide 50

Slide 50 text

@[email protected] Optimising for a short mean time to restore

Slide 51

Slide 51 text

@[email protected] Loose coupling = small blast radius

Slide 52

Slide 52 text

@[email protected] https://lamport.azurewebsites.net/pubs/distributed-system.txt “A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable”

Slide 53

Slide 53 text

@[email protected] Richard I Cook - https://www.adaptivecapacitylabs.com/ HowComplexSystemsFail.pdf

Slide 54

Slide 54 text

@[email protected] Richard I Cook - https://www.adaptivecapacitylabs.com/ HowComplexSystemsFail.pdf Distributed systems need to be built with multiple layers of defense against failure

Slide 55

Slide 55 text

@[email protected] Build resilience in

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

@[email protected] Know when something important is broken

Slide 59

Slide 59 text

@[email protected] Checks running in January 2021 at the Financial Times

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

@[email protected] Focus on business capabilities

Slide 63

Slide 63 text

@[email protected] Monitor your business capabilities

Slide 64

Slide 64 text

@[email protected] Work out what's going on

Slide 65

Slide 65 text

@[email protected] Monitoring is not enough

Slide 66

Slide 66 text

@[email protected] Observability: can you infer what’s going on in the system by looking at external outputs?

Slide 67

Slide 67 text

@[email protected] Tracing events through your system

Slide 68

Slide 68 text

Slide 69

Slide 69 text

@[email protected] 4. Spending most of your time on meaningful work

Slide 70

Slide 70 text

@[email protected] Autonomous teams have a lot of things to know about

Slide 71

Slide 71 text

@[email protected] Maintaining microservices means constant work

Slide 72

Slide 72 text

@[email protected] Product development teams can’t be completely autonomous

Slide 73

Slide 73 text

@[email protected] Platform engineering

Slide 74

Slide 74 text

@[email protected] Platform engineering Engineering Enablement

Slide 75

Slide 75 text

@[email protected] Paving the road

Slide 76

Slide 76 text

@[email protected] https://charity.wtf/2018/12/02/software-sprawl-the-golden-p ath-and-scaling-teams-with-agency/

Slide 77

Slide 77 text

@[email protected] ● Self service ● Well-documented ● Discoverable

Slide 78

Slide 78 text

@[email protected] 5. Not having to start again

Slide 79

Slide 79 text

@[email protected] Without work, systems get messy

Slide 80

Slide 80 text

@[email protected] Starting again is appealing!

Slide 81

Slide 81 text

@[email protected] Rebuilding stops you delivering value

Slide 82

Slide 82 text

@[email protected] ● £10 million ● 2 years in maintenance mode

Slide 83

Slide 83 text

@[email protected] Microservices *should* make it easy

Slide 84

Slide 84 text

@[email protected] "Habitability is the characteristic of source code that enables people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently." Habitability and Piecemeal Growth, Richard P Gabriel, https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

Slide 85

Slide 85 text

@[email protected] 6. Keeping risk to an acceptable level

Slide 86

Slide 86 text

@[email protected] Know your estate

Slide 87

Slide 87 text

@[email protected] https://www.infoq.com/presentations/productivity-ft/

Slide 88

Slide 88 text

@[email protected] Active ownership

Slide 89

Slide 89 text

@[email protected] Services need to be actively owned, by a team

Slide 90

Slide 90 text

Slide 91

Slide 91 text

@[email protected] Be flexible on tech choices only where you need to be

Slide 92

Slide 92 text

@[email protected] The paved road allows you to make global decisions around risk

Slide 93

Slide 93 text

@[email protected] ● Safe ● Secure ● Reliable by default

Slide 94

Slide 94 text

@[email protected] Guardrails and governance

Slide 95

Slide 95 text

@[email protected] The FT’s guardrails

Slide 96

Slide 96 text

Slide 97

Slide 97 text

@[email protected] log4shell

Slide 98

Slide 98 text

@[email protected] What next for microservices? https://thenewstack.io/the-future-of-microservices-more-abstr actions/

Slide 99

Slide 99 text

@[email protected] https://thenewstack.io/the-future-of-microservices-more-abstr actions/ We have mature well-designed microservice frameworks

Slide 100

Slide 100 text

@[email protected] https://thenewstack.io/the-future-of-microservices-more-abstr actions/ Open telemetry provides a standard for distributed telemetry data

Slide 101

Slide 101 text

@[email protected] Improving developer experience is the next challenge

Slide 102

Slide 102 text

@[email protected] https://thenewstack.io/the-future-of-microservices-more-abstr actions/

Slide 103

Slide 103 text

@[email protected] Daniel Bryant, quoted in https://thenewstack.io/ the-future-of-microservices-more-abstractions/ “companies.. are creating a Heroku-like CLI for their developers, so that a command like ‘create new microservice’ spins up some scaffolding, plugs into CI, plugs into pipelines, plugs into observability”

Slide 104

Slide 104 text

@[email protected] https://backstage.io/

Slide 105

Slide 105 text

@[email protected] https://redmonk.com/jgovernor/2022/02/21/what-is-developer -experience-a-roundup-of-links-and-goodness/ “organisations want developers to spend more time coding and less time thinking about and working on infrastructure”

Slide 106

Slide 106 text

@[email protected] https://redmonk.com/jgovernor/2022/02/21/what-is-developer -experience-a-roundup-of-links-and-goodness/ “Why would a developer put up with a poor developer experience when they can likely find a job that better aligns with their needs and preferences?”

Slide 107

Slide 107 text

@[email protected] Wrapping up…

Slide 108

Slide 108 text

@[email protected] Fast flow is important

Slide 109

Slide 109 text

@[email protected] Which means you need: ● zero-downtime deployments ● loose coupling

Slide 110

Slide 110 text

@[email protected] Microservices reduce build & deploy complexity and increase operational complexity

Slide 111

Slide 111 text

@[email protected] Autonomy comes with responsibility Jason Yip, Thoughts on the Spotify model, https://jchyip.medium.com/my- critique-of-the-spotify-model-part-1-197d335ef7af

Slide 112

Slide 112 text

@[email protected] You need some scaffolding

Slide 113

Slide 113 text

@[email protected] Everything is a bit distributed now

Slide 114

Slide 114 text

@[email protected] https://www.oreilly.com/library/view/enabling-microservice-su ccess/9781098130787/

Slide 115

Slide 115 text

@[email protected] Slides: https://speakerdeck/sarahwells/code-camp23- enabling-microservice-success Contact: @[email protected] https://www.linkedin.com/in/sarahjwells1/