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

[VDB23] The Hitchhiker's guide to Software Architecture Design

[VDB23] The Hitchhiker's guide to Software Architecture Design

Designing a new platform is always tricky to set up.

How to start? What is the best strategy to adopt while designing a platform? What kind of architecture should we deploy: event streaming, orchestration, or choreography?

For a brand-new platform: "Donut @ Home", we will proceed a live architecture study.

After analysing the customer needs, brainstorming, and exchanging our ideas, we will choose among all the potential solutions the *least worst* option.

You will be asked to validate our design and the different implementation examples.

At the end of this talk, you will have tips and tricks for thinking about it and starting working on architecture studies in complete peace of mind.

Alexandre Touret

May 23, 2023
Tweet

More Decks by Alexandre Touret

Other Decks in Programming

Transcript

  1. VoxxedDaysBrussels 2023
    The Hitchhiker's guide
    to
    Software Architecture Design
    Raphaël SEMETEYS - Alexandre TOURET

    View full-size slide

  2. Alexandre TOURET
    Software Architect
    @touret_alex
    blog.touret.info
    Raphaël SEMETEYS
    Software Architect
    @RaphaelSemeteys
    blog.worldline.tech
    Who are we?
    2

    View full-size slide

  3. We design payments technology
    that powers the growth of millions
    of businesses around the world.
    Who are we?
    3 |
    @worldlinetech

    View full-size slide

  4. Business View
    5

    View full-size slide

  5. SLOs
    (Service
    Level
    Objectives)
    Availability,
    TTR, Data
    loss
    Compliancy?
    Cloud vs
    On-premise
    Requirements
    7

    View full-size slide

  6. Fill and store every key architectural decision as close as possible to the code
    Architecture Decision Record
    # Title
    # Status
    - [ ] proposed
    - [X] accepted
    - [ ] rejected
    - [ ] deprecated
    - [ ] superseded
    # Context
    # Decision
    # Consequences
    # ADR01 – Cloud hosting
    # Status
    - [X] proposed
    - [ ] accepted
    - [ ] rejected
    - [ ] deprecated
    - [ ] superseded
    # Context
    Capacity of the platform capacity must adapt according
    to Donut@Home success
    # Decision
    Cloud hosting to optimize pay-per-use and intrinsic
    scalability
    # Consequences
    Cloud-native architecture (12 factors)
    8

    View full-size slide

  7. Risk Analysis?
    Source: riskstorming.com
    9

    View full-size slide

  8. Low
    1
    Medium
    2
    High
    3
    Low
    1
    Medium
    2
    High
    3
    - Unavailability of
    middleware
    - Database access
    error
    - SAN error
    - VLAN network error
    Probability
    Impact
    10

    View full-size slide

  9. Business view wrap-up
    • Donut design and delivery application
    User needs
    • Retrieved Time Objective, Recovery Point Objective: ?
    • TTR: 90% of the transactions up to 2sec
    • Availability: 95%
    • Number of users: 500 000 / day → Currently a little bit foggy
    • Ability to easily integrate new features
    Requirements
    • Compliant with banking and payment standards
    • GDPR compliant
    Compliancy
    • Track every decision into ADRs
    • Look into and write risks to deal with (or not)
    Last but not least
    11

    View full-size slide

  10. Architecture Approach
    12

    View full-size slide

  11. c4model.com
    C4
    13

    View full-size slide

  12. C4 System View
    14

    View full-size slide

  13. C4 Container View
    15

    View full-size slide

  14. Functional View
    16

    View full-size slide

  15. Functional view
    Alexandre’s…
    17

    View full-size slide

  16. Functional view
    …and Raphaël’s
    18

    View full-size slide

  17. 19
    In your opinion?
    1
    ’ ? Or ë ’ ?
    2
    Delivery
    Payment
    Payment
    Delivery

    View full-size slide

  18. Functional view
    In the end
    20

    View full-size slide

  19. To sum-up
    Design the architecture
    through several views
    Confront different
    viewpoints
    Avoid
    « Not Invented Here »
    21

    View full-size slide

  20. Application View
    22

    View full-size slide

  21. Main characteristics of an architecture
    Evolutivity Modularity Cost Performance
    Simplicity Testability
    Fault
    tolerance
    23

    View full-size slide

  22. Types of architecture
    24|
    Monolith SOA Orchestration
    Event
    Driven
    Micro
    services

    View full-size slide

  23. Orchestration
    27

    View full-size slide

  24. Event Driven
    28

    View full-size slide

  25. Microservices
    29

    View full-size slide

  26. When to use them?
    Monolith SOA
    Orchest-
    ration
    Event
    Driven
    Micro-
    services
    Evolutivity ▲ ▲▲▲ ▲ ▲▲▲▲▲ ▲▲▲▲▲
    Scalability ▲ ▲▲▲ ▲▲▲▲
    ▲▲▲▲▲
    ▲▲▲▲▲
    Modularity ▲ ▲▲▲▲ ▲▲▲ ▲▲▲▲ ▲▲▲▲▲
    Cost ▲▲▲▲▲ ▲▲▲▲ ▲ ▲▲▲ ▲▲▲
    Performance ▲▲ ▲▲▲ ▲▲ ▲▲▲▲▲ ▲▲
    Simplicity ▲▲▲▲▲ ▲▲▲ ▲ ▲ ▲
    Testability ▲▲ ▲▲▲ ▲ ▲▲ ▲▲▲▲
    Fault
    tolerance
    ▲ ▲▲▲▲ ▲▲▲ ▲▲▲▲▲ ▲▲▲▲▲
    30

    View full-size slide

  27. It's a capability of the platform more than just a bunch of tools...
    Think Observability by Design!
    36
    Visualize
    Alert
    Metrics
    Traces
    Logs
    Global
    Dashboard
    Technical console
    for advanced logs
    Prometheus
    ecosystem
    Elastic
    ecosystem
    CaaS
    specific
    OpenTelemetry
    ecosystem
    Legacy

    View full-size slide

  28. Low
    1
    Medium
    2
    High
    3
    Low
    1
    Medium
    2
    - Response times are
    too high (> SLO)
    - Unavailability of
    external systems
    - Unobservable platform
    High
    3
    - Unavailability of
    middleware
    - Database access error
    - SAN error
    - VLAN network error
    Probability
    Impact
    37

    View full-size slide

  29. Some good practices
    Risk analysis
    at different levels
    Accept new
    points of view
    When to
    innovate?
    Organizational
    impacts
    38

    View full-size slide

  30. Infrastructure View
    39

    View full-size slide

  31. Private or Public Cloud?
    40

    View full-size slide

  32. How to use the Cloud?
    41
    PaaS
    CaaS
    IaaS
    SaaS
    Consume external services
    Use managed services
    Deploy containers
    Deploy virtual machines
    Payment …
    Quarkus
    Spring
    Boot
    MongoDB
    PostgreSQL Kafka
    APIM IAM Observability

    View full-size slide

  33. ’ q
    - Involve Business, Devs, Ops, Finance, Experts
    - Formalize commitment if necessary
    - Possible validation steps
    Architecture validation
    42
    Regarding infrastructure
    Verification of feasibility or technical hypotheses (POC) -
    Non Functional Requirements -
    Sizing elements -
    Iterative work!

    View full-size slide

  34. Conclusion
    43 |

    View full-size slide

  35. 46 |
    Approach Best practices & tools
    • Step back
    • Remain open-minded
    • Share w/ all the
    stakeholders
    • Formalise and trace
    • Collaborate & iterate
    • Align different views
    • Blueprints & Patterns
    • Technical roadmap
    • Keep pragmatic
    Attitude

    View full-size slide

  36. Thanks for your
    feedback!
    https://bit.ly/vdb_archi
    47 |

    View full-size slide

  37. ’ !
    Follow & get in touch
    @RaphaelSemeteys
    linkedin.com/in
    /raphaelsemeteys
    blog.worldline.tech
    @WorldlineTech
    Follow our tech team: Follow us:
    @touret_alex
    linkedin.com/in
    /atouret
    48 |

    View full-size slide

  38. Explore our jobs in tech:
    careers.worldline.com
    Want to shape
    how the world pays
    and get paid?
    49 |

    View full-size slide