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

Enabling Microservice Success

Enabling Microservice Success

Microservices can be a very effective approach to speeding up delivery of value to your organisation and to your customers. If you get them right.
If you don’t, then microservices are just something that makes everything you do more complicated, from working out where things are going wrong to upgrading the same dependency in tens or hundreds of services.
After nearly ten years experience of building and operating microservice architectures at the Financial Times, Sarah will talk about:

What does ‘successfully using microservices’ look like?
What key aspects of organisational structure and culture do you need?
Where are the biggest challenges, and what can you do to avoid them?

A288fb976fc633cde90a2bc19bf2b5a6?s=128

Sarah Wells

May 03, 2022
Tweet

More Decks by Sarah Wells

Other Decks in Technology

Transcript

  1. @sarahjwells Enabling Microservice Success Sarah Wells

  2. @sarahjwells https://app.wombo.art/card/a65d2834-7662-4f39-9819-57a08b2e4f9e

  3. @sarahjwells

  4. @sarahjwells Why do microservices?

  5. @sarahjwells CV++

  6. @sarahjwells • Deployment frequency • Lead time for changes •

    Change failure rate • Time to restore service
  7. @sarahjwells Microservices are a decoupled architecture

  8. @sarahjwells Microservices are also distributed, and there are lots of

    them
  9. @sarahjwells What does microservice success look like?

  10. @sarahjwells What does microservice success look like?

  11. @sarahjwells What does a successful software development organisation look like?

  12. @sarahjwells Can you… • move fast enough to experiment? •

    work on the highest value features? • respond appropriately to production issues? • minimise failure cascades? • spend most of your time on meaningful work? • avoid having to start again?
  13. @sarahjwells Can you move fast enough to experiment?

  14. @sarahjwells • Deployment frequency • Lead time for changes

  15. @sarahjwells Isolating the impact of a change

  16. @sarahjwells • Deployment frequency • Lead time for changes

  17. @sarahjwells Faster feedback on what we have built

  18. @sarahjwells Avoiding the sunk cost fallacy

  19. @sarahjwells True experimentation https://www.slideshare.net/TechWellPresentations/ experiments-the-good-the-bad-and-the-beautiful

  20. @sarahjwells True experimentation →A/B testing

  21. @sarahjwells

  22. @sarahjwells https://continuousdelivery.com/

  23. @sarahjwells Continuous delivery → loosely coupled architecture https://continuousdelivery.com/implementing/architecture/

  24. @sarahjwells Continuous delivery → loosely coupled architecture → autonomous empowered

    teams https://continuousdelivery.com/implementing/architecture/
  25. @sarahjwells Separate releasing code from turning on functionality

  26. @sarahjwells What you need to have in place • Autonomous

    empowered cross-functional teams • Continuous delivery • A/B testing • Feature flags Can you move fast enough to experiment?
  27. @sarahjwells Can you work on the highest value features?

  28. @sarahjwells Prioritising across teams, not just within them

  29. @sarahjwells If everyone works differently, moving people is hard

  30. @sarahjwells Big pieces of work

  31. @sarahjwells High level alignment of priorities

  32. @sarahjwells OKRs Objective: Everyone uses github for source control as

    measured by Key result: 100% of repositories moved to github
  33. @sarahjwells Ways to work together • collaboration • x-as-a-service •

    facilitation https://teamtopologies.com/key-concepts
  34. @sarahjwells Collaboration: working together for a defined period of time

    https://teamtopologies.com/key-concepts
  35. @sarahjwells X-as-a-service: one team provides a service that the other

    consumes https://teamtopologies.com/key-concepts
  36. @sarahjwells Facilitation: one team helps and mentors another team https://teamtopologies.com/key-concepts

  37. @sarahjwells Long term support → contract testing → monitoring of

    ‘business capabilities’
  38. @sarahjwells What you need to have in place • The

    ‘right’ amount of standardisation • OKRs or some other way to co-ordinate priorities • Effective ways of working together Can you work on the highest value features?
  39. @sarahjwells What you need to have in place • Contract

    testing • End to end monitoring Can you work on the highest value features?
  40. @sarahjwells Can you respond appropriately to production issues?

  41. @sarahjwells • Change failure rate • Time to restore service

  42. @sarahjwells Know when something important is broken

  43. @sarahjwells

  44. @sarahjwells Richard I Cook - https://www.skybrary.aero/bookshelf/books/5926.pdf Distributed systems are generally

    in a state of ‘grey failure’
  45. @sarahjwells

  46. @sarahjwells

  47. @sarahjwells Restore some level of service in an acceptable amount

    of time
  48. @sarahjwells

  49. @sarahjwells

  50. @sarahjwells https://medium.com/ft-product-technology/the-advent- of-change-api-8dae0f95245e

  51. @sarahjwells Services need to be actively owned, by a team

  52. @sarahjwells Observability: can you infer what’s going on in the

    system by looking at external outputs?
  53. @sarahjwells

  54. @sarahjwells What you need to have in place • Service

    levels/SLOs • Multi region or multi-AZ services • Automatic scaling, automatic failover • Services with active ownership Can you respond appropriately to production issues?
  55. @sarahjwells What you need to have in place • High

    quality runbooks • Observability • Change APIs Can you respond appropriately to production issues?
  56. @sarahjwells Can you minimise failure cascades?

  57. @sarahjwells You need to build defensively

  58. @sarahjwells Be a good citizen yourself

  59. @sarahjwells Optimise for fast startup and graceful shutdown https://12factor.net/disposability

  60. @sarahjwells Service meshes and API gateways can help

  61. @sarahjwells What you need to have in place • 12

    factor applications • Throttling/load shedding • Back off and retry/circuit breakers Can you minimise failure cascades?
  62. @sarahjwells Can you spend most of your time on meaningful

    work?
  63. @sarahjwells You need platform and enabling teams

  64. @sarahjwells

  65. @sarahjwells They should be building a paved road https://charity.wtf/2018/12/02/software-sprawl-the-golden-pa th-and-scaling-teams-with-agency/

  66. @sarahjwells Microservices means doing everything many times

  67. @sarahjwells Removing toil is a retention thing

  68. @sarahjwells What you need to have in place • Platform

    and enabling teams • A paved road • Use of Paas/SaaS options Can you spend most of your time on meaningful work?
  69. @sarahjwells Can you avoid having to start again?

  70. @sarahjwells Entropy is inevitable https://qconlondon.com/london2022/presentation/no-next-nex t-fighting-entropy-microservices-architecture

  71. @sarahjwells Rebuilding stops you delivering value

  72. @sarahjwells https://medium.com/ft-product-technology/designing-a-sustai nable-front-end-toolset-for-ft-com-f37c59d27eeb

  73. @sarahjwells What you need to have in place • Active

    ownership of services • Platform and enabling teams • A paved road, including within a group • Use of Paas/SaaS options • Tackle technical debt Can you avoid having to start again?
  74. @sarahjwells To summarise

  75. @sarahjwells Can you… • move fast enough to experiment? •

    work on the highest value features? • respond appropriately to production issues? • minimise failure cascades? • spend most of your time on meaningful work? • avoid having to start again?
  76. @sarahjwells You need: Organisation structure & culture • Autonomous empowered

    cross-functional teams • The ‘right’ amount of standardisation • OKRs or some other way to co-ordinate priorities • Effective ways of working together • Platform and enabling teams • A paved road
  77. @sarahjwells You need: Architecting & building systems • Use of

    Paas/SaaS options • Multi region or multi-AZ services • Automatic scaling, automatic failover • Guardrails • 12 factor applications
  78. @sarahjwells You need: Architecting & building systems • Continuous delivery

    • A/B testing • Feature flags • Throttling/load shedding • Back off and retry/circuit breakers
  79. @sarahjwells You need: Keeping things up & running • Contract

    testing • End to end monitoring • Service levels/SLOs • Services with active ownership • Tackle technical debt • Invest in good runbooks • Observability rather than monitoring • Change APIs
  80. @sarahjwells Are microservices the right answer?

  81. @sarahjwells Thank you!