[TADX 23] 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. TADx 1 plateforme à concevoir 2 architectes 3 possibilités Raphaël SEMETEYS - Alexandre TOURET
2. Alexandre TOURET Architecte logiciel @touret_alex blog.touret.info Raphaël SEMETEYS Architecte logiciel @RaphaelSemeteys blog.worldline.tech Qui sommes-nous? 2
3. We design payments technology that powers the growth of millions of businesses around the world. Who are we? 3 | @worldlinetech
5. Vue métier 5
7. SLOs (Service Level Objectives) Disponibilité, temps de réponse, pertes de données Contraintes réglementaires? Cloud vs On- premise Exigences 7
8. 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
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 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
12. Démarche d’architecture 12
13. c4model.com Modèle C4 13
14. Vue C4 System cce ts iles rom trusted customers 14
15. Vue C4 Container ular a a ri oot 15
16. La vue fonctionnelle 16
17. 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
18. 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
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 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
20. 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
21. 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
22. La vue applicative 22
23. Pri ci ales caractéristiques d’u e architecture Évolutivité Modularité Coût Performance Simplicité Testabilité Tolérance aux pannes 23
24. T es 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. 32 L L ha dles deli er orders o li e secure credit card a me t
34. 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
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. ’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
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. ’i rastructure 39
40. Cloud Privé ou Public ? 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 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 !
43. Conclusion 43 |
44. ’ 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
45. Merci de votre retour! https://bit.ly/tadx0321 47 |
46. 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 |
47. Explore our jobs in tech: careers.worldline.com Want to shape how the world pays and get paid? 49 |