Une plateforme à concevoir, deux architectes: trois possibilités ?

Slide 1

Slide 1 text

2023 Merci à nos sponsors

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Alexandre TOURET Architecte logiciel @touret_alex blog.touret.info Raphaël SEMETEYS Architecte logiciel @RaphaelSemeteys blog.worldline.tech Qui sommes-nous? 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Vue métier 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Référencez et stockez au plus près du code chaque décision structurante 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 Donut@Home # 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) 9

Slide 10

Slide 10 text

Une analyse de risques ? Source: riskstorming.com 10

Slide 11

Slide 11 text

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 11

Slide 12

Slide 12 text

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 12

Slide 13

Slide 13 text

Démarche d’architecture 13

Slide 14

Slide 14 text

c4model.com Modèle C4 14

Slide 15

Slide 15 text

Vue C4 System cce ts iles rom trusted customers 15

Slide 16

Slide 16 text

Vue C4 Container ular a a ri oot 16

Slide 17

Slide 17 text

La vue fonctionnelle 17

Slide 18

Slide 18 text

Vue fonctionnelle Celle d’Alexandre… 18 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

Slide 19

Slide 19 text

Vue fonctionnelle …puis celle de Raphaël 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

Slide 20

Slide 20 text

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 20 Quel est votre avis ? 1 L ’Alexandre ? Ou celle de Raphaël ? 2 Livraison Paiement Paiement Livraison

Slide 21

Slide 21 text

Vue fonctionnelle La synthèse 21 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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

La vue applicative 23

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Monolithe 26 L L L L

Slide 27

Slide 27 text

SOA 27 L L L L L L L L L

Slide 28

Slide 28 text

Orchestration 28

Slide 29

Slide 29 text

Event Driven 29

Slide 30

Slide 30 text

Microservices 30 L L L L L L L

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

L L 32

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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 36 ou ou ou

Slide 37

Slide 37 text

’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 37

Slide 38

Slide 38 text

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 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

’i rastructure 40

Slide 41

Slide 41 text

Cloud Privé ou Public ? 41

Slide 42

Slide 42 text

Quels ’ du Cloud ? 42 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é

Slide 43

Slide 43 text

Conformité aux exigences/contraintes des vues - Impliquer Métier, Devs, Ops, Finance, Experts - ’ si nécessaire - Eventuelles étapes de validation Validatio de l’architecture 43 ’ Vérification de aisabilité ou d’h othèses tech iques (PO ) - Non Functionnal Requirements - Eléments de dimensionnement - Travail itératif !

Slide 44

Slide 44 text

Conclusion 44 |

Slide 45

Slide 45 text

• Analyser les risques aide à la décision • Confrontez les points de vue (encore!) • Sachez innover • Faites attention aux freins liés à l’or a isatio La vue métier La vue fonctionnelle La vue applicative La vue d’infra- structure Conclusion d’ lexa dre • Le besoin • Les exigences (NFRs) • Les contraintes réglementaires • Commencez à identifier les risques • Formalisez et tracez! • Déclinez votre architecture en plusieurs vues • Confrontez les points de vue • Syndrôme « Not Invented Here » • Impliquez les OPS dès le début • Validez la conformité de l’exi e ce et des contraintes • Travaillez itérativement 45

Slide 46

Slide 46 text

Conclusion de Raphaël Chaque vue doit être challengée Documentez les aspects structurants ’architecture est un « objet vivant » 46 |

Slide 47

Slide 47 text

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 47 |

Slide 48

Slide 48 text

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