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

Microservices: what does good look like? (Nov 2023)

Microservices: what does good look like? (Nov 2023)

The microservice architecture has become increasingly popular over the past decade. Its key benefits include significantly improving the developer experience and accelerating software delivery. Sadly, however, microservices have often been widely misunderstood and used inappropriately. As a result, many organizations have struggled to benefit from their adoption.

In this presentation I'll describe the key characteristics of the microservice architecture and how it differs from the monolithic architecture. You will learn when you should use microservices and when you should not. I'll describe the ideal developer experience when using the microservice architecture.You will also learn what other changes you must make to your organization when adopting microservices.

Chris Richardson

December 04, 2023
Tweet

More Decks by Chris Richardson

Other Decks in Programming

Transcript

  1. @crichardson
    Microservices: what does
    good look like?
    Chris Richardson


    Founder of Eventuate.io


    Founder of the original CloudFoundry.com


    Author of POJOs in Action and Microservices Patterns


    @crichardson


    [email protected]


    http://adopt.microservices.io
    Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved

    View full-size slide

  2. @crichardson
    Presentation goal
    Why is rapid, frequent, reliable and sustainable
    delivery of software essential?


    What does that mean for software architecture?


    Compare and contrast architectural patterns:
    Monolithic architecture and Microservice
    architecture

    View full-size slide

  3. @crichardson
    About Chris
    http://adopt.microservices.io

    View full-size slide

  4. @crichardson
    Agenda
    Modern software delivery


    Architecting for modern software delivery


    The monolithic architecture is not an anti-pattern


    The microservice architecture pattern

    View full-size slide

  5. @crichardson
    O
    VID
    -19
    https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2
    https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4
    https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/
    The success triangle
    Process: DevOps/Continuous Delivery & Deployment
    Organization:


    Network of small,


    loosely coupled, product teams
    IT must deliver software


    rapidly, frequently, reliably and sustainably


    Businesses must be
    nimble, agile and


    innovate faster
    S/W
    VUCA
    Architecture:


    ???

    View full-size slide

  6. @crichardson
    Quantifying with the DORA
    metrics
    Deployment frequency - how frequently changes are pushed
    to production


    Lead time - time from commit to deploy


    Change failure rate - how frequently a change breaks
    production


    Time to restore service - how long to recover from a failed
    deployment
    https://dora.dev/

    View full-size slide

  7. @crichardson
    2023 State of DevOps report

    View full-size slide

  8. @crichardson
    Statistical averages hide what
    good looks like
    Deployment frequency - for each
    commit


    Lead time - under an hour


    Change failure rate - really low


    Time to restore service - really
    short
    https://dora.dev/

    View full-size slide

  9. The research shows:


    high-performance = $$$
    Software Delivery
    Performance


    Lead time, Deployment
    frequency, Mean Time To
    Restore, Change Failure %
    Organizational Performance


    Pro
    fi
    tability, Productivity,
    Market share
    $
    Impacts

    View full-size slide

  10. What is DevOps?
    Set of principles and
    practices where
    developers, testers
    (dev) and IT operations
    (ops) collaborate and
    communicate to
    deliver software
    rapidly, frequently, and
    reliably
    http://itrevolution.com/devops-handbook
    Three ways
    Flow
    Feedback
    Learning

    View full-size slide

  11. @crichardson
    DevOps: automated continuous
    deployment + telemetry
    Production
    Commit


    code+tests


    frequently


    to trunk


    Automated deployment
    pipeline
    Continuous
    integration
    Tests +
    static
    analysis
    (Git) repository for


    Code


    AND
    Infrastructure con
    fi
    guration


    (e.g. GitOps)
    No handoffs
    Automated


    deployment
    Canary
    releases
    Observability
    infrastructure
    Telemetry
    Developer

    View full-size slide

  12. @crichardson
    DevOps: Hypothesis-driven
    development
    Microsoft study: 2/3rds of ideas have zero or negative value.


    HiPPO (highest paid person's opinion) is too common


    Therefore:
    Treat requirements as hypothesis


    Run as-cheap-as-possible experiments in production with users


    Base decisions on data gathered


    View full-size slide

  13. Big idea: fast feedback
    Getting changes into production as fast as possible
    after writing it


    Validates what was written: code, feature, …


    Change is still fresh in the mind of the developer
    Big task => series of very small tasks

    View full-size slide

  14. High performance
    organization: team of teams
    5-9 people - promotes trust


    Long-lived - enables trust and
    high performance


    Empowered/autonomous


    Typically owns suitably sized
    software “component”


    Promotes long-term
    sustainable development


    Prevents cognitive overload
    https://teamtopologies.com/key-concepts

    View full-size slide

  15. @crichardson
    https://teamtopologies.com/key-concepts

    View full-size slide

  16. @crichardson
    Team interaction: primarily X-as-a Service
    https://teamtopologies.com/key-concepts

    View full-size slide

  17. @crichardson
    Teams primarily collaborate to
    (re)de
    fi
    ne APIs

    View full-size slide

  18. Development in high performing
    organizations
    “Complete their work without communicating and
    coordinating with people outside their team”


    “Make large-scale changes to the design of their system
    without depending on other teams to make changes in
    their systems or creating signi
    fi
    cant work for other teams”


    “We can do most of our testing without requiring an
    integrated environment.”


    “We can and do deploy or release our application
    independently of other applications/services it depends
    on.”

    View full-size slide

  19. @crichardson
    Developer experience (DevEx)
    encompasses how developers
    feel about, think about, and
    value their work.
    https://queue.acm.org/detail.cfm?id=3595878

    View full-size slide

  20. @crichardson
    https://queue.acm.org/detail.cfm?id=3595878
    Minimize meetings,
    interruptions, …

    View full-size slide

  21. @crichardson
    Great
    DevEx
    Developers can focus with
    minimal interruptions
    Minimal unnecessary
    cognitive load
    Fast feedback from local
    tools, deployment
    pipeline, production
    environment, …

    View full-size slide

  22. @crichardson
    Measuring DevEx


    Survey teams


    +


    Gather metrics, e.g. DORA

    View full-size slide

  23. @crichardson
    https://queue.acm.org/detail.cfm?id=3595878

    View full-size slide

  24. @crichardson
    But we are a bank: we can’t
    do DevOps?! Yes you can!
    • Customer facing application servicing over 80 million accounts.


    • 25 Agile teams with approx .150+ engineers geographically distributed.


    • Reactive based micro services architecture in the Cloud


    • 60 deployment pipelines - ~4300 releases over the last 12 months


    • Mature engineering practices


    • Automated control gates.
    https://itrevolution.com/articles/biz-and-tech-partnership-toward-ten-no-fear-releases-per-day-at-capital-one/


    https://videos.itrevolution.com/watch/468711236/
    US$38.37 billion 50K people
    e.g. Need two person approval => pair programming

    View full-size slide

  25. @crichardson
    Agenda
    Modern software delivery


    Architecting for modern software delivery


    The monolithic architecture is not an anti-pattern


    The microservice architecture pattern

    View full-size slide

  26. About software architecture
    “The software architecture of a computing system is the
    set of structures needed to reason about the system,
    which comprise software elements, relations among
    them, and properties of both.”


    Documenting Software Architectures, Bass et al
    Primary goal = satisfy non-functional requirements

    View full-size slide

  27. Architecting for…

    View full-size slide

  28. @crichardson
    Architectural requirement #1:
    loose coupling
    Order
    Management
    Customer
    Management
    Develops Develops
    Unaffected
    by changes
    to the other
    Conway’s law
    Loosely coupled = work independently
    Loosely coupled
    Degree of design-time coupling = probability of lockstep changes

    View full-size slide

  29. @crichardson
    Loose coupling is a
    fundamental principle of
    software design


    Ignore at your peril!
    of classes, packages, modules, services, applications, …
    V

    View full-size slide

  30. @crichardson
    Architectural requirements #2 and
    #3: testability and deployability
    Production
    Automated deployment pipeline
    >= 1 commit


    / developer


    / day
    Must be fast
    running
    Must be
    reliable
    Must be testable using
    automated tests
    deployment
    Must be
    locally
    testable
    commit

    View full-size slide

  31. @crichardson
    Successful applications live for a long time, e.g. 10 years,
    20 years, …


    BUT
    Technology changes: Programming languages,
    frameworks, …
    Time
    Technology A Technology B
    V1 V2 V3 V…
    Importance
    The importance of a technology changes over time
    Relying on technology that is unimportant to market
    Not using technology that is important to the market
    Murer, Stephan,Bruno Bonati Consulting, Bruno Bonati. Managed Evolution: A Strategy for Very Large Information Systems

    View full-size slide

  32. @crichardson
    Architecting for sustainable
    software development
    Evolvability
    Must be able to incrementally upgrade
    the technology stack
    API encapsulates the
    technology stack

    View full-size slide

  33. @crichardson
    Architecting for DevEx
    https://queue.acm.org/detail.cfm?id=3595878
    Loose coupling
    Testability


    Deployability


    Observability
    Simplicity

    View full-size slide

  34. Architectural requirements
    Testable
    Deployable
    Loosely coupled
    Evolvable
    Observable
    Simple as possible
    +
    The usual:


    Security


    Scalability


    Performance



    View full-size slide

  35. @crichardson
    Problem: How to organize subdomains
    into components to meet these
    requirements?

    View full-size slide

  36. @crichardson
    Monolith vs. Microservices
    One component


    =


    Monolith
    Two or components


    =


    Microservices

    View full-size slide

  37. @crichardson
    Agenda
    Modern software delivery


    Architecting for modern software delivery


    The monolithic architecture is not an anti-pattern


    The microservice architecture pattern

    View full-size slide

  38. @crichardson
    The monolith architecture
    An architectural style that
    structures the application
    that structures the
    application as


    a single deployable/
    executable component
    that uses a single
    database.

    View full-size slide

  39. @crichardson
    Github Repository
    «Gradle Project»
    FtgoApplication
    «Gradle Subproject»
    main
    main
    «Gradle Subproject»
    orders
    orders.web
    «Gradle Subproject»
    customerAPI
    orders.
    domain
    «Gradle Subproject»
    customers
    customers.
    persistence
    orders.
    persistence
    Customer team
    Order team
    Deployment pipeline
    Production
    FTGO
    Application
    Executable JAR
    customers.
    domain
    customers.
    web
    customers.
    api
    Modular monolith: domain-oriented
    not layered
    Promotes loose build-time coupling
    Vertical slices/domains
    Clear ownership
    Single large repo
    Slow or complicated
    https://microservices.io/post/architecture/2023/07/31/how-modular-can-your-monolith-go-part-1.html

    View full-size slide

  40. @crichardson
    Simple but… successful
    applications keep growing…
    Small
    monolith
    Large
    monolith
    10s of developers 100s of developers

    View full-size slide

  41. @crichardson
    Dif
    fi
    cult to achieve fast
    feedback
    Production
    Git push


    con
    fl
    icts
    SLOW
    deployment
    pipeline
    SLOW local
    development Becomes a
    bottleneck
    Infrequent


    Deployments

    View full-size slide

  42. @crichardson
    Lack of team autonomy
    Large
    monolith
    code base
    100s of developers
    Modular design can
    help but there’s only a
    single code base, …
    “Oops I broke the build”
    “We need to upgrade
    dependency X”

    View full-size slide

  43. @crichardson
    Developer experience:
    monolithic architecture
    Large monolith
    • High cognitive load


    • Less autonomy


    • More meetings


    • Slow feedback
    Single classpath,


    Large code base,
    Slow deployment
    pipeline, …
    Simple (e.g. ACID txns)


    development BUT
    You

    View full-size slide

  44. @crichardson
    Single technology stack
    Monolith
    Application
    code
    Framework X Vn
    Framework Y Vn
    Library Z Vn
    Language runtime


    v …
    Upgrades are global =
    potentially large task
    Can’t experiment with
    alternative frameworks
    or languages

    View full-size slide

  45. @crichardson
    Agenda
    Modern software delivery


    Architecting for modern software delivery


    The monolithic architecture is not an anti-pattern


    The microservice architecture pattern

    View full-size slide

  46. @crichardson
    The microservice architecture
    An architectural style that
    structures the application
    as


    a collection of two or
    more


    independently deployable


    loosely coupled


    services

    View full-size slide

  47. @crichardson
    API
    Service de
    fi
    nition
    Operations
    Event


    Publisher
    Commands
    Queries
    Synchronous


    REST/gRPC
    Asynchronous


    Messaging
    Events
    Event


    Subscriber
    API


    Client
    Invokes


    Operations
    Events
    Collaborators
    Responsibilities
    «subdomain»
    Order
    Management
    «subdomain»
    Customer
    Management
    Business
    logic

    View full-size slide

  48. @crichardson
    Independently deployable = production-
    ready after being tested in isolation
    https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html

    View full-size slide

  49. @crichardson
    Replace end-to-end
    acceptance tests


    with


    Per-service acceptance tests

    View full-size slide

  50. Loosely (design-time*)
    coupled
    Changing services in lock step reduces
    productivity:


    API changes/evolution


    Complexity of non-atomic changes of
    independently deployable services


    Coordination between teams


    Therefore:
    Tightly coupled subdomains should be
    packaged together


    Services should have small, stable APIs
    * vs runtime and build-time coupling
    https://microservices.io/post/architecture/2023/03/28/microservice-architecture-essentials-loose-coupling.html
    Customer
    Service
    Customer
    Subdomain


    Order Service
    Order
    Subdomain
    API
    Loose coupling is essential

    View full-size slide

  51. @crichardson
    Microservice architecture !=
    lots of little services
    Service
    Service
    Subdomain
    A
    Subdomain
    B
    Team A Team B
    Service
    Subdomain
    A
    Subdomain
    B
    OR
    Team A Team B
    #itDepends

    View full-size slide

  52. @crichardson
    A service exists
    to solve a
    problem
    Service
    Service
    «Subdomain» A
    «Aggregate»
    X
    «Subdomain» B
    «Aggregate»
    Y
    Simple components
    Team autonomy
    Fast deployment pipeline
    Support multiple technology stacks
    Segregate by characteristics
    Repulsive dark energy forces
    https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html

    View full-size slide

  53. @crichardson
    A service should
    not exist if it
    creates worse
    problems
    https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html
    Subdomain A
    «Aggregate»
    X
    Subdomain B
    «Aggregate»
    Y
    Service A Service B
    Simple interactions
    Efficient interactions
    Prefer ACID over BASE
    Minimize runtime coupling
    Minimize design time coupling
    Generates
    SystemOperation()
    Collaboration
    Attractive dark matter forces

    View full-size slide

  54. @crichardson
    Assemblage: designing a
    microservice architecture
    https://microservices.io/post/architecture/2023/02/09/assemblage-architecture-de
    fi
    nition-process.html
    Just enough
    services

    View full-size slide

  55. @crichardson
    Message
    Broker
    Consequences of distribution:
    distributed operations
    Order
    Service
    createOrder()
    Restaurant
    Service
    Customer
    Service
    GET /restaurant/{id}
    The network:


    • Complexity


    • Partial failure


    • Runtime coupling


    • Latency


    • Performance


    • …

    View full-size slide

  56. @crichardson
    Consequences of independent
    deployability: no end-to-end tests
    Consumer
    Provider
    (service)
    Test in


    isolation
    Consumer-driven
    contract testing
    Test in


    isolation
    Contract = example interaction
    Testing in production:


    • Separate deployment from release


    • Canary release


    • Feature
    fl
    ags


    • Chaos engineering


    • …

    View full-size slide

  57. @crichardson
    Consequences of loose design-time
    coupling: database per service with
    eventual consistency
    Order Service
    Customer
    Service
    Orders


    Database
    Customers
    Database
    API
    createOrder()
    reserveCredit()
    BEGIN transaction





    COMMIT transaction
    BEGIN transaction





    COMMIT transaction

    View full-size slide

  58. @crichardson
    Distributed operation => use
    collaboration patterns
    API Composition
    Provider
    Service
    Service
    query()
    Composer
    Provider
    Service
    Provider
    Service
    CQRS
    Provider
    Service
    Service
    query()
    View
    Provider
    Service
    Provider
    Service
    Event
    Event
    Event
    Service
    Service Service
    Transaction
    Compensating
    transaction
    Transaction
    Compensating
    transaction
    Transaction
    Compensating
    transaction
    command()
    Saga
    Service
    Service
    command()
    Replica Source
    Event
    Command-side replica
    Commands
    Queries
    https://microservices.io/post/patterns/2023/07/29/service-collaboration-patterns.html

    View full-size slide

  59. @crichardson
    Developer experience:
    microservice architecture
    Service
    Small part of a large application
    Service …
    Service …
    Service …
    collaborators
    A
    P
    I
    • Less cognitive load


    • More autonomy incl.
    technical


    • Less meetings


    • Faster feedback
    You
    A
    P
    I
    A
    P
    I
    A
    P
    I
    Service …
    Service …
    clients

    View full-size slide

  60. @crichardson
    Focus on internal functionality
    - not collaboration
    Loosely coupled
    Service
    A
    P
    I
    Tightly
    coupled
    Service
    API
    Good ✅ Bad ❌
    Constant collaboration with other teams
    Mostly works independently
    Subdomain
    X
    Subdomain
    Y
    Subdomain
    Z Focus
    Focus

    View full-size slide

  61. @crichardson
    Collaborate to de
    fi
    ne APIs
    For example: Order Management must invoke new Coupon
    Management to redeem coupon


    Teams meet to co-create contracts (example request/
    responses) that de
    fi
    ne redeemCoupon() API endpoint


    Teams then work independently:


    Order Service team - write biz logic using test doubles


    Coupon Service team - implement redemption logic

    View full-size slide

  62. @crichardson
    Per-service technology stack
    management
    Upgrading the technology stack can be done one service at
    time, e.g. Spring Boot 2.7.x to 3.x


    Safely experiment with new technologies


    Implement a service using a new technology


    Minimal investment


    Easily reversed if experiment fails

    View full-size slide

  63. @crichardson
    Summary
    Modern software development
    IT must deliver software rapidly, frequently,
    reliably, and sustainably
    DORA Metrics
    Lead time
    Deployment frequency
    Change failure rate
    Mean time to recover
    Measured by
    Outcome
    Better business performance $$$$$
    profitability, productivity, and market share
    Correlates with

    View full-size slide

  64. @crichardson
    Summary
    Modern software development
    IT must deliver software rapidly, frequently,
    reliably, and sustainably
    DORA Metrics
    Lead time
    Deployment frequency
    Change failure rate
    Mean time to recover
    Measured by
    Outcome
    Better business performance $$$$$
    profitability, productivity, and market share
    Correlates with
    Achieved using
    Process:
    DevOps
    Organization:
    A network of small, loosely
    coupled, teams
    Architecture
    Success
    Triangle
    Great
    DexEx
    Fast feedback
    Frequent flow state
    Low cognitive load

    View full-size slide

  65. @crichardson
    Summary
    Modern software development
    IT must deliver software rapidly, frequently,
    reliably, and sustainably
    DORA Metrics
    Lead time
    Deployment frequency
    Change failure rate
    Mean time to recover
    Measured by
    Outcome
    Better business performance $$$$$
    profitability, productivity, and market share
    Correlates with
    Achieved using
    Process:
    DevOps
    Organization:
    A network of small, loosely
    coupled, teams
    Architecture
    Success
    Triangle
    Great
    DexEx
    Fast feedback
    Frequent flow state
    Low cognitive load
    Architectural requirements
    Testable
    Deployable
    Observable
    Loosely coupled
    Evolvable
    Simple

    View full-size slide

  66. @crichardson
    Summary
    Modern software development
    IT must deliver software rapidly, frequently,
    reliably, and sustainably
    DORA Metrics
    Lead time
    Deployment frequency
    Change failure rate
    Mean time to recover
    Measured by
    Outcome
    Better business performance $$$$$
    profitability, productivity, and market share
    Correlates with
    Achieved using
    Process:
    DevOps
    Organization:
    A network of small, loosely
    coupled, teams
    Architecture
    Success
    Triangle
    Great
    DexEx
    Fast feedback
    Frequent flow state
    Low cognitive load
    Architectural requirements
    Testable
    Deployable
    Observable
    Loosely coupled
    Evolvable
    Simple
    Shaped by
    Smaller/Simpler
    Applications
    Large/Complex
    applications
    Independently deployable
    Loosely coupled
    Monolith
    Microservices
    Subdomain A
    «Aggregate»
    X
    Subdomain B
    «Aggregate»
    Y
    Service A Service B
    Attraction
    Simple interactions
    Prefer ACID over BASE
    Minimize runtime coupling
    Efficient inter-service
    communication
    Minimize design time coupling
    Simple components
    Team autonomy
    Fast deployment pipeline
    Support multiple technology stacks
    Cost effective scaling
    Segregate regulated software
    Segregate highly available components
    Repulsion
    Metaphor for
    Metaphor for
    Dark energy
    Dark matter

    View full-size slide

  67. @crichardson
    @crichardson [email protected]
    http://adopt.microservices.io
    Questions?

    View full-size slide