[VOLCAMPIO24] Une plateforme 2 architectes 3 possibilités

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Alexandre TOURET Architecte logiciel Developer advocate @touret_alex blog.touret.info Raphaël SEMETEYS Architecte entreprise Developer advocate @RaphaelSemeteys https://dev.to/raphiki Qui sommes-nous? 2

Slide 3

Slide 3 text

We design payments technology that powers the growth of millions of businesses around the world. 7000+ engineers in over 40 countries Managing 43+ billion transactions per year €250M spent in R&D every year Handling 150+ payment methods #1 European payment processor

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Vue métier 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

SLO (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é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 Truffade@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 Truffade à 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 normes bancaires et paiement • Le traitement des données doit être conforme au RGPD Les contraintes réglementaires • Tracer les décisions dans des ADRs, formaliser les risques à traiter (ou pas) • Définir un vocabulaire métier commun (DDD) 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 ccepts files from trusted customers 14

Slide 15

Slide 15 text

Vue C4 Container n ular a a prin oot 15

Slide 16

Slide 16 text

La vue fonctionnelle 16

Slide 17

Slide 17 text

Vue fonctionnelle Celle d’Alexandre… 17 nables ruffade orderin billin handles deli er orders online secure credit card pa ment tores all the bankin information about suppliers customers handles bank transfers

Slide 18

Slide 18 text

Vue fonctionnelle …puis celle de Raphaël 18 nables ruffade orderin billin online secure credit card pa ment handles deli er orders tores all the bankin information about suppliers customers handles bank transfers

Slide 19

Slide 19 text

nables ruffade orderin billin handles deli er orders online secure credit card pa ment tores all the bankin information about suppliers customers handles bank transfers nables ruffade orderin billin online secure credit card pa ment handles deli er orders tores all the bankin information about suppliers customers handles bank transfers 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 nables ruffade orderin billin online secure credit card pa ment handles deli er orders tores all the bankin information about suppliers customers handles bank transfers

Slide 21

Slide 21 text

Vue fonctionnelle : en résumé Déclinez l’architecture en plusieurs vues Confrontez les points de vue Évitez le syndrome « Not Invented Here » 21

Slide 22

Slide 22 text

La vue applicative 22

Slide 23

Slide 23 text

Principales caractéristiques d’une architecture Évolutivité Modularité Coût Performance Simplicité Testabilité Tolérance aux pannes 23

Slide 24

Slide 24 text

pes 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

L L handles deli er orders online secure credit card pa ment 32

Slide 33

Slide 33 text

Slide 34

Slide 34 text

L L React React Node pescript Docker Node pescript Docker a a prin oot Docker Post re a a uarkus Docker Post re a a prin oot Docker Mon oD afka afka onnect afka onnect online secure credit card pa ment 34 ou ou ou

Slide 35

Slide 35 text

Slide 36

Slide 36 text

’est une capacité de la plate-forme plus qu’un assembla e d’outils… Pensez à l’Obser abilité dès la conception ! : ’ é 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

’infrastructure 39

Slide 40

Slide 40 text

Le Cloud oui, mais lequel ? 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 Validation de l’architecture 42 ’ Vérification de faisabilité ou d’h pothèses techniques (PO ) - Non Functional Requirements - Eléments de dimensionnement - Travail itératif !

Slide 43

Slide 43 text

Conclusion 43 |

Slide 44

Slide 44 text

’ 44 | Démarche Pratiques & Outils • Prendre du recul • Rester ou ert d’esprit • Echanger avec tous • Formaliser et tracer • Collaborer et itérer • Aligner les vues • Patrons d’architecture • Choix technologiques • Rester pragmatique Attitude

Slide 45

Slide 45 text

Don’t be a stran 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 45 | Feedback

Slide 46

Slide 46 text

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