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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Vue métier 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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 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) 8

Slide 9

Slide 9 text

Une analyse de risques ? Source: riskstorming.com 9

Slide 10

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

Slide 11

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

Slide 12

Slide 12 text

Démarche d’architecture 12

Slide 13

Slide 13 text

c4model.com Modèle C4 13

Slide 14

Slide 14 text

Vue C4 System cce ts iles rom trusted customers 14

Slide 15

Slide 15 text

Vue C4 Container ular a a ri oot 15

Slide 16

Slide 16 text

La vue fonctionnelle 16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 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 » 21

Slide 22

Slide 22 text

La vue applicative 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Monolithe 25 L L L L

Slide 26

Slide 26 text

SOA 26 L L L L L L L L L

Slide 27

Slide 27 text

Orchestration 27

Slide 28

Slide 28 text

Event Driven 28

Slide 29

Slide 29 text

Microservices 29 L L L L L L L

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

L L 31

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Slide 34

Slide 34 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 34 ou ou ou

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

’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

Slide 37

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

’i rastructure 39

Slide 40

Slide 40 text

Cloud Privé ou Public ? 40

Slide 41

Slide 41 text

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é

Slide 42

Slide 42 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 42 ’ Vérificationde aisabilité ou d’h othèses tech iques (PO ) - Non FunctionalRequirements - Eléments de dimensionnement - Travail itératif !

Slide 43

Slide 43 text

Conclusion 43 |

Slide 44

Slide 44 text

’ 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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 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 48 |

Slide 47

Slide 47 text

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