[VOLCAMPIO24] Une plateforme 2 architectes 3 possibilités

Transcript

1. 1 plateforme à concevoir 2 architectes 3 possibilités Raphaël SEMETEYS - Alexandre TOURET
2. 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
3. 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
5. Vue métier 5
7. SLO (Service Level Objectives) Disponibilité, temps de réponse, pertes de données Contraintes réglementaires? Cloud vs On- premise Exigences 7
8. 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
9. Une analyse de risques ? Source: riskstorming.com 9
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
11. 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
12. Démarche d’architecture 12
13. c4model.com Modèle C4 13
14. Vue C4 System ccepts files from trusted customers 14
15. Vue C4 Container n ular a a prin oot 15
16. La vue fonctionnelle 16
17. 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
18. 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
19. 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
20. 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
21. Vue fonctionnelle : en résumé Déclinez l’architecture en plusieurs vues Confrontez les points de vue Évitez le syndrome « Not Invented Here » 21
22. La vue applicative 22
23. Principales caractéristiques d’une architecture Évolutivité Modularité Coût Performance Simplicité Testabilité Tolérance aux pannes 23
24. pes d’architecture 24| Monolithe SOA Orchestration Event Driven Micro services
25. Monolithe 25 L L L L
26. SOA 26 L L L L L L L L L
27. Orchestration 27
28. Event Driven 28
29. Microservices 29 L L L L L L L
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
31. L L 31
32. L L handles deli er orders online secure credit card pa ment 32
34. 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
35. 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 35 ou ou ou
36. ’est une capacité de la plate-forme plus qu’un assembla e d’outils… Pensez à l’Obser abilité dès la conception ! : ’ é j 36
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
38. Quelques bonnes pratiques Analyse de risques à différents niveaux Ne restez pas sur vos acquis ! Quand innover ? Impacts organisationnels 38
39. ’infrastructure 39
40. Le Cloud oui, mais lequel ? 40
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é
42. 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 !
43. Conclusion 43 |
44. ’ 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
45. 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
46. Explore our jobs in tech: careers.worldline.com Want to shape how the world pays and get paid? 46 |