[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.

Transcript

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

   View 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 Slide

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

   View Slide

4. View Slide

5. Business View
   5
   

   View Slide

6. View Slide

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

   View Slide

8. 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 Slide

9. Risk Analysis?
   Source: riskstorming.com
   9
   

   View Slide

10. 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 Slide

11. 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 Slide

12. Architecture Approach
    12
    

    View Slide

13. c4model.com
    C4
    13
    

    View Slide

14. C4 System View
    14
    

    View Slide

15. C4 Container View
    15
    

    View Slide

16. Functional View
    16
    

    View Slide

17. Functional view
    Alexandre’s…
    17
    

    View Slide

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

    View Slide

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

    View Slide

20. Functional view
    In the end
    20
    

    View Slide

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

    View Slide

22. Application View
    22
    

    View Slide

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

    View Slide

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

    View Slide

25. Monolith
    25
    

    View Slide

26. SOA
    26
    

    View Slide

27. Orchestration
    27
    

    View Slide

28. Event Driven
    28
    

    View Slide

29. Microservices
    29
    

    View Slide

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

    View Slide

31. View Slide

32. View Slide

33. View Slide

34. 34
    or
    or
    or
    

    View Slide

35. 35
    or
    or
    or
    

    View Slide

36. 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 Slide

37. 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 Slide

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

    View Slide

39. Infrastructure View
    39
    

    View Slide

40. Private or Public Cloud?
    40
    

    View Slide

41. 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 Slide

42. ’ 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 Slide

43. Conclusion
    43 |
    

    View Slide

44. 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 Slide

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

    View Slide

46. ’ !
    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 Slide

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

    View Slide