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

Transcript

1. 2023 Merci à nos sponsors
2. SnowCampIO2023 1 plateforme à concevoir 2 architectes 3 possibilités Raphaël SEMETEYS - Alexandre TOURET
3. Alexandre TOURET Architecte logiciel @touret_alex blog.touret.info Raphaël SEMETEYS Architecte logiciel @RaphaelSemeteys blog.worldline.tech Qui sommes-nous? 3
4. We design payments technology that powers the growth of millions of businesses around the world. Who are we? 4 | @worldlinetech
6. Vue métier 6
8. SLOs (Service Level Objectives) Disponibilité, temps de réponse, pertes de données Contraintes réglementaires? Cloud vs On- premise Exigences 8
9. 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
10. Une analyse de risques ? Source: riskstorming.com 10
11. 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
12. 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
13. Démarche d’architecture 13
14. c4model.com Modèle C4 14
15. Vue C4 System cce ts iles rom trusted customers 15
16. Vue C4 Container ular a a ri oot 16
17. La vue fonctionnelle 17
18. 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
19. 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
20. 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
21. 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
22. 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
23. La vue applicative 23
24. Pri ci ales caractéristiques d’u e architecture Évolutivité Modularité Coût Performance Simplicité Testabilité Tolérance aux pannes 24
25. T es d’architecture 25| Monolithe SOA Orchestration Event Driven Micro services
26. Monolithe 26 L L L L
27. SOA 27 L L L L L L L L L
28. Orchestration 28
29. Event Driven 29
30. Microservices 30 L L L L L L L
31. Quand les utiliser ? Monolithe SOA Orchest- ration Event Driven Micro- services Evolutivité ▲ ▲▲▲ ▲ ▲▲▲▲▲ ▲▲▲▲▲ Scalabilité ▲ ▲▲▲ ▲▲▲▲ ▲▲▲▲▲ ▲▲▲▲▲ Modularité ▲ ▲▲▲▲ ▲▲▲ ▲▲▲▲ ▲▲▲▲▲ Coût ▲▲▲▲▲ ▲▲▲▲ ▲ ▲▲▲ ▲▲▲ Performance ▲▲ ▲▲▲ ▲▲ ▲▲▲▲▲ ▲▲ Simplicité ▲▲▲▲▲ ▲▲▲ ▲ ▲ ▲ Testabilité ▲▲ ▲▲▲ ▲ ▲▲ ▲▲▲▲ Tolérance aux pannes ▲ ▲▲▲▲ ▲▲▲ ▲▲▲▲▲ ▲▲▲▲▲ 31
32. L L 32
33. 33 L L ha dles deli er orders o li e secure credit card a me t
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
36. 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
37. ’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
38. 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
39. Quelques bonnes pratiques Analyse de risques à différents niveaux Ne restez pas sur vos acquis ! Quand innover ? Impacts organisationnels 39
40. ’i rastructure 40
41. Cloud Privé ou Public ? 41
42. 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é
43. 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 !
44. Conclusion 44 |
45. • 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 fonction- nelle La vue applica- tive 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
46. Conclusion de Raphaël Chaque vue doit être challengée Documentez les aspects structurants ’architecture est un « objet vivant » 46 |
47. 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 |
48. Explore our jobs in tech: careers.worldline.com Want to shape how the world pays and get paid? 48 |