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

[TADX 23] Une plateforme à concevoir, deux architectes: trois possibilités ?

[TADX 23] Une plateforme à concevoir, deux architectes: trois possibilités ?

La conception d'une plateforme est toujours délicate à initier.

Comment démarrer? Quelle est la démarche à adopter pour concevoir une architecture? Quel est le modèle à appliquer: event streaming, orchestration ou chorégraphie?
Au travers d'un besoin utilisateur, nous prendrons notre "casquette" d'architecte et déroulerons devant vous une étude pour une toute nouvelle plateforme "Donut @ Home".

Après avoir analysé le besoin, confronté nos idées et convictions devant vous, nous choisirons, parmi toutes les solutions possibles, la *"moins pire"*.

Nous vous solliciterons pour valider notre conception et les exemples d'implémentation possibles.

A la fin de cette présentation, vous aurez des clés pour penser et démarrer les études de vos architectures en toute sérénité (ou presque).

Alexandre Touret

March 23, 2023
Tweet

More Decks by Alexandre Touret

Other Decks in Programming

Transcript

  1. TADx
    1 plateforme à concevoir
    2 architectes
    3 possibilités
    Raphaël SEMETEYS - Alexandre TOURET

    View Slide

  2. Alexandre TOURET
    Architecte logiciel
    @touret_alex
    blog.touret.info
    Raphaël SEMETEYS
    Architecte logiciel
    @RaphaelSemeteys
    blog.worldline.tech
    Qui sommes-nous?
    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. 4

    View Slide

  5. Vue métier
    5

    View Slide

  6. 6

    View Slide

  7. SLOs (Service
    Level Objectives)
    Disponibilité,
    temps de
    réponse, pertes
    de données
    Contraintes
    réglementaires?
    Cloud vs On-
    premise
    Exigences
    7

    View Slide

  8. Référencezet stockezau plus près du code chaque décisionstructurante d’architecture
    Architecture Decision Record
    # Title
    # Status
    - [ ] proposed
    - [X] accepted
    - [ ] rejected
    - [ ] deprecated
    - [ ] superseded
    # Context
    # Decision
    # Consequences
    # ADR01 – Hébergement Cloud
    # Status
    - [X] proposed
    - [ ] accepted
    - [ ] rejected
    - [ ] deprecated
    - [ ] superseded
    # Context
    La capacité de la plate-forme doit s’adapter en
    fonction du succès de la nouvelle offre [email protected]
    # Decision
    Hébergement de type Cloud pour optimiser le coût à
    l’usage et disposer de scalabilité intrinsèque
    # Consequences
    Disposer d’une architecture Cloud-native (12 factors)
    8

    View Slide

  9. Une analyse de risques ?
    Source: riskstorming.com
    9

    View Slide

  10. Low
    1
    Medium
    2
    High
    3
    Low
    1
    Medium
    2
    High
    3
    - Les middlewares
    indisponibles
    - Erreur d'accès à la
    database
    - Erreur SAN
    - Erreur réseau
    VLAN HS
    Probability
    Impact
    10

    View Slide

  11. Vue métier : synthèse
    • Une application de création et de livraison de Donuts à Domicile
    Le besoin
    • Retrieved Time Objective, Recovery Point Objective: ?
    • Temps de réponse: 90% des transactions doivent être réalisées en moins de 2sec
    • Disponibilité: 95%
    • Nombre d’utilisateurs: cible métier à 500 000 / jour →Peu de visibilité sur les pics
    • Capacité à intégrer facilement des nouveautés
    Les exigences
    • Le paiement doit être conforme aux norme bancaires et paiement
    • Le traitement des données doit être conforme au RGPD
    Les contraintes réglementaires
    • Tracer les décisions dans des ADRs
    • Toujours intégrer et formaliser les risques à traiter (ou pas)
    Autres bonnes pratiques
    11

    View Slide

  12. Démarche d’architecture
    12

    View Slide

  13. c4model.com
    Modèle C4
    13

    View Slide

  14. Vue C4 System
    cce ts iles rom trusted
    customers
    14

    View Slide

  15. Vue C4 Container
    ular a a ri oot
    15

    View Slide

  16. La vue fonctionnelle
    16

    View Slide

  17. Vue fonctionnelle
    Celle d’Alexandre…
    17
    ables do uts orderi
    billi ha dles deli er orders
    o li e secure credit card
    a me t
    tores all the ba i
    i ormatio about su liers
    customers ha dles ba
    tra s ers

    View Slide

  18. Vue fonctionnelle
    …puis celle de Raphaël
    18
    ables do uts orderi
    billi
    o li e secure credit card
    a me t
    ha dles deli er orders
    tores all the ba i
    i ormatio about su liers
    customers ha dles ba
    tra s ers

    View Slide

  19. ables do uts orderi
    billi
    o li e secure credit card
    a me t
    ha dles deli er orders
    tores all the ba i
    i ormatio about su liers
    customers ha dles ba
    tra s ers
    ables do uts orderi
    billi ha dles deli er orders
    o li e secure credit card
    a me t
    tores all the ba i
    i ormatio about su liers
    customers ha dles ba
    tra s ers
    19
    Quel est votre avis ?
    1
    L ’Alexandre ? Ou celle de Raphaël ?
    2
    Livraison
    Paiement
    Paiement
    Livraison

    View Slide

  20. Vue fonctionnelle
    La synthèse
    20
    ables do uts orderi
    billi
    ha dles deli er orders
    o li e secure credit card
    a me t
    tores all the ba i
    i ormatio about su liers
    customers ha dles ba
    tra s ers

    View Slide

  21. Vue fonctionnelle : en résumé
    Décli ez l’architecture
    en plusieurs vues
    Confrontez les
    points de vue
    Evitez le syndrome
    « Not Invented Here »
    21

    View Slide

  22. La vue applicative
    22

    View Slide

  23. Pri ci ales caractéristiques d’u e architecture
    Évolutivité Modularité Coût Performance
    Simplicité Testabilité
    Tolérance
    aux pannes
    23

    View Slide

  24. T es d’architecture
    24|
    Monolithe SOA Orchestration
    Event
    Driven
    Micro
    services

    View Slide

  25. Monolithe
    25
    L
    L
    L L

    View Slide

  26. SOA
    26
    L
    L
    L L
    L L
    L L
    L

    View Slide

  27. Orchestration
    27

    View Slide

  28. Event Driven
    28

    View Slide

  29. Microservices
    29
    L
    L
    L
    L
    L
    L
    L

    View Slide

  30. Quand les utiliser ?
    Monolithe SOA
    Orchest-
    ration
    Event
    Driven
    Micro-
    services
    Evolutivité ▲ ▲▲▲ ▲ ▲▲▲▲▲ ▲▲▲▲▲
    Scalabilité ▲ ▲▲▲ ▲▲▲▲
    ▲▲▲▲▲
    ▲▲▲▲▲
    Modularité ▲ ▲▲▲▲ ▲▲▲ ▲▲▲▲ ▲▲▲▲▲
    Coût ▲▲▲▲▲ ▲▲▲▲ ▲ ▲▲▲ ▲▲▲
    Performance ▲▲ ▲▲▲ ▲▲ ▲▲▲▲▲ ▲▲
    Simplicité ▲▲▲▲▲ ▲▲▲ ▲ ▲ ▲
    Testabilité ▲▲ ▲▲▲ ▲ ▲▲ ▲▲▲▲
    Tolérance
    aux pannes
    ▲ ▲▲▲▲ ▲▲▲ ▲▲▲▲▲ ▲▲▲▲▲
    30

    View Slide

  31. L
    L
    31

    View Slide

  32. 32
    L
    L
    ha dles deli er orders
    o li e secure credit card
    a me t

    View Slide

  33. 33

    View Slide

  34. L
    L
    eact
    eact
    Node T escri t Doc er
    Node T escri t Doc er
    a a ri oot Doc er
    Post re
    a a uar us Doc er
    Post re
    a a ri oot Doc er
    o oD
    a a
    a a o ect
    a a o ect
    o li e secure credit card
    a me t
    34
    ou
    ou
    ou

    View Slide

  35. L
    L
    eact
    eact
    Node T escri t Doc er
    Node T escri t Doc er
    a a ri oot Doc er
    Post re
    a a uar us Doc er
    Post re
    a a ri oot Doc er
    o oD
    a a
    a a o ect
    a a o ect
    o li e secure credit card
    a me t
    35
    ou
    ou
    ou

    View Slide

  36. ’est u e capacité de la plate- orme lus qu’u assembla e d’outils…
    Pe sez à l’Obser abilité dès la co ce tio !
    : ’ é j
    36

    View Slide

  37. Low
    1
    Medium
    2
    High
    3
    Low
    1
    Medium
    2
    - Les temps de réponse
    sont trop élevés (>
    SLO)
    - Indisponibilité des
    systèmes externes
    - Plate-forme peu
    observable
    High
    3
    - Les middlewares
    indisponibles
    - Erreur d'accès à la
    database
    - Erreur SAN
    - Erreur réseau VLAN
    HS, ou élément réseau
    HS
    Probability
    Impact
    37

    View Slide

  38. Quelques bonnes pratiques
    Analyse de risques
    à différents niveaux
    Ne restez pas
    sur vos acquis !
    Quand innover ? Impacts
    organisationnels
    38

    View Slide

  39. ’i rastructure
    39

    View Slide

  40. Cloud Privé ou Public ?
    40

    View Slide

  41. Quels ’
    du Cloud ?
    41
    PaaS
    CaaS
    IaaS
    SaaS
    Consommation de services externes
    Utilisation de services managés
    Déploiement de conteneurs
    Déploiement de machines virtuelles
    Paiement …
    Quarkus
    Spring
    Boot
    MongoDB
    PostgreSQL Kafka
    APIM IAM Observabilité

    View Slide

  42. Conformité aux exigences/contraintes des vues
    - Impliquer Métier, Devs, Ops, Finance, Experts
    - ’ si nécessaire
    - Eventuelles étapes de validation
    Validatio de l’architecture
    42

    Vérificationde aisabilité ou d’h othèses tech iques (PO ) -
    Non FunctionalRequirements -
    Eléments de dimensionnement -
    Travail itératif !

    View Slide

  43. Conclusion
    43 |

    View Slide


  44. 46 |
    Démarche Pratiques & Outils
    • Prendre du recul
    • ester ou ert d’es rit
    • Echanger avec tous
    • Formaliser et tracer
    • Collaborer et itérer
    • Aligner les vues
    • Patro s d’architecture
    • Choix technologiques
    • Rester pragmatique
    Attitude

    View Slide

  45. Merci de votre retour!
    https://bit.ly/tadx0321
    47 |

    View Slide

  46. Do ’t be a stra er!
    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