SnowcampIO 2023 - 1 plateforme à concevoir + 2 architectes = 3 solutions
•Télécharger en tant que PPTX, PDF•
0 j'aime•10 vues
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és nos idées et convictions devant vous, nous choisirons, parmi toutes les solutions possibles, quelle est 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).
Recommandé
Recommandé
Contenu connexe
Similaire à SnowcampIO 2023 - 1 plateforme à concevoir + 2 architectes = 3 solutions
Similaire à SnowcampIO 2023 - 1 plateforme à concevoir + 2 architectes = 3 solutions (20)
Plus de Raphaël Semeteys
Plus de Raphaël Semeteys (12)
SnowcampIO 2023 - 1 plateforme à concevoir + 2 architectes = 3 solutions
- 1. SnowCampIO 2023 1 plateforme à concevoir 2 architectes 3 possibilités Raphaël SEMETEYS - Alexandre TOURET
- 2. 2023 Merci à nos sponsors
- 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
- 5. 5
- 6. Vue métier 6
- 7. 7
- 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
- 15. Vue C4 System 15
- 19. Vue fonctionnelle …puis celle de Raphaël 19
- 20. 20 Quel est votre avis ? 1 La solution d’Alexandre ? Ou celle de Raphaël ? 2 Livraison Paiement Paiement Livraison
- 22. Vue fonctionnelle : en résumé Déclinez l’architecture en plusieurs vues Confrontez les points de vue Evitez le syndrome « Not Invented Here » 22
- 24. Principales caractéristiques d’une architecture Évolutivité Modularité Coût Performance Simplicité Testabilité Tolérance aux pannes 24
- 25. Types d’architecture 25| Monolithe SOA Orchestration Event Driven Micro services
- 26. Monolithe 26
- 27. SOA 27
- 28. Orchestration 28
- 29. Event Driven 29
- 30. Microservices 30
- 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. 32
- 33. 33
- 34. 34
- 35. 35 ou ou ou
- 36. 36 ou ou ou
- 37. C’est une capacité de la plate-forme plus qu’un assemblage d’outils… Pensez à l’Observabilité dès la conception ! Exemple : architecture d’observabilité sur un gros projet 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
- 41. Cloud Privé ou Public ? 41
- 42. Quels modes d’utilisation 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 - Formaliser l’engagement si nécessaire - Eventuelles étapes de validation Validation de l’architecture 43 Pour l’infrastructure Vérification de faisabilité ou d’hypothèses techniques (POC) - 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’organisation La vue métier La vue fonction- nelle La vue applica- tive La vue d’infra- structure Conclusion d’Alexandre • 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’exigence et des contraintes • Travaillez itérativement 45
- 46. Conclusion de Raphaël Chaque vue doit être challengée Documentez les aspects structurants L’architecture est un « objet vivant » 46 |
- 47. Merci de votre retour! https://openfeedback.io /snowcamp23/2023-01-27 47 |
- 48. Don’t be a stranger! 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 |
- 49. Explore our jobs in tech: careers.worldline.com Want to shape how the world pays and get paid? 49 |
Notes de l'éditeur
- A: Nouveau projet => Comment vous y prendre ? Votre chef de projet vous contacte la semaine prochaine pour un nouveau projet de vente en ligne
- A se présente R se présente
- A ne s’appesantit pas sur la partie Corporate
- A: Concevoir l’architecture de Donut @ Home R: Sérieux ?! R: projet Zébulon A: les besoins d’abord… A: démarche R: TOGAF A: Euh… NON ! R: Ok [Next slide]
- R: besoins client et utilisateurs finaux A: le pourquoi [Next slide]
- A: résumé du besoin métier R: différent de Zébulon en fait… R: plein de questions NFR (dispo, temps de réponse, perte données) A: hop, hop, hop… par étapes => [Next slide]
- A: exigences (dispo 100 => 95%, délais < 2s, sécu et perte pas clair encore) R: eCommerce => RGDP et bancaire/paiement A: Cloud ou pas ? R: scalabilité et peu visibilité sur #users => ADR sur choix Cloud A: ADR ? R: [Next slide]
- R: formalisme simple pour tracer et partager decision d’architecture ADR Cloud : contexte de forte de scalabilité sans vision sur la progression + impact Cloud native A: concentrons nous sur les risques R: analyse de risques [Next slide]
- R: matrice de risques classés par probabilité/impacts + suivi des actions de mitigation A: je peux commecer à remplir sur la base de REX de projets passes [Next slide]
- A: voici je qu’on peut mettre + étoffé au fur et à mesure A: ok vision plus claire, faisons le point sur la vision métier [Next slide]
- A: présente les deux premiers blocs R: présente les deux derniers
- R: formaliser vision métier et fonctionnelle => quel formalisme ? A: C4 R: Archimate… tu peux présenter ça vite fait ?
- A présente rapidement la vision derrière C4
- A présente rapidement la vision derrière C4
- A présente rapidement la vision derrière C4 R: ok vues d’architecture selon les parties prenantes, ça me rappelle qqch… [Next slide]
- R: vue fonctionnelle = C4 Context, modélisons chacun de notre coté !
- A: paiement externalisé (éviter contraintes bancaires/paiement) => se concentrer sur l’aspect e-commerce
- R: même découpage mais vision un peu différente, livraison via PF mutu, paiement à construire A : ok pour livraison, paiement => pas cœur de métier, bancaire/paiement=> y’a des gens qui font ça très bien… R : d’accord, comment décide t’on ? => Prenons l’avis du public
- R: vote à main levée A et R : on préfère un mix des deux en fait…! R: être ouvert mais aussi savoir s’imposer en justifiant et traçant les choix
- A : se recentrer sur le besoin métier R: 1 plate-forme + 2 architectes = 3 possibilités => SnowCamp?
- A traite les 2 premiers sujets : points de vue et C4 + ne pas rester sur ses acquis R le dernier : réinventer une roue carrée (livraison), make or buy (ex. paiement)
- A: transition = principales caractéristiques et contraintes d’une architecture applicative [Next slide]
- A balaye les principaux critères R: passons en revue les principaux types d’architecture [Next slide]
- R: présentons rapidement les principaux types d’architecture pour les comparer à la fin
- R: decoupage 3-tiers, middle = 1 seul noeud d’execution, decoupage logique du code possible => modular monolith
- R: modules => services avec nœuds d’exécution différents, dispatch par le front, cohérence via BDD
- A: couche d’orchestration et intégration, ESB => couplage et frictions
- A: synchronisation des services via évènements R: chorégraphie VS chef d’orchestre A: et les microservices pour terminer R: style ou mode A: regardons ça… [Next slide]
- A: découpage plus fin => souplesse code et équipes, attention au découpage plus qu’en SOA R: ok si on fait une synthèse de tout ça [Next slide]
- (pas aller trop vite sur ce tableau) R: tableau issu de nos REX, aide à la décision ; scalabilité et new features (métier) => élimine Monolithe et Orchestration [Animate] A: ESB pas simple et cher => microservices pour modularité R: event-driven pour les perfs ? A: microservices pour la testabilité R: oui important de penser aux équipes A: penchons-nous sur la vue C4
- A: découpage en 3 microservices car contextes différents R: les perfs me tracassent [Animation] http synchrones… [Next slide]
- R : messages asynchrones entre Billing et Shopping et aussi avec ext A: ça donne un mix des types d’archi A : passons au choix des technos, microservices : Spring Boot A : regardons notre TechRadar [Next slide]
- R: regardons notre TechRadar => Quarkus pour Customer plus du backoffice et sourcing Dev plus facile A: Ok on a donc les deux Spring Boot et Quarkus [Next slide]
- A: reco prod sur BDD = PostgreSQL (relationnel) ou MongoDB (docs) [A Animate] à decider plus tard A: front : ReactJS + Node.js car Classique R [Next slide]
- R: HypeJS ? A: pas de Hype-Driven-Development ! R: [R Animate] ok pour le front [R Animate] Kafka car très bon retours prod (exploitabilité et observabilité) [Next slide]
- R: Parenthèse sur Observabilité, dès conception, capacité, exemple architecture d’observabilité gros projet A: mettre à jour la matrice de risque [Next slide]
- A: ajout PF observable + temps de réponse mitigés par event-processing
- A: synthèse sur la vue applicative : risques + confronter points de vues R: laisser l’espace pour innover mais quand innover (aide TechRadar) + impacts orga et humains (ex. tests, run), pour des solutions inter orga : problèmes !
- A : vue technique et physique de l’architecture, important pour les équipe run + traduire vie précédentes en technos et ressources systèmes mais aussi financières R : en phase même si Cloud sinon le prix scalera tout seul aussi
- A: choix à faire concernant le Cloud justement + cloud privé = Kubernetes ou Openshift ? [A Animate] ou CSP ? R: et avant ça : quels modes d’utilisation du Cloud [R Animate]
- R: quels composants en IaaS (VM) et CaaS (conteneurs) ? Quels services managés en PaaS ou carrément externalisés en SaaS ? A: l’heure tourne… ok pour aujourd’hui => prochaines réunions archi mais aussi avec autres équipes (métier, build, run…)
- R: oui important de valider l’architecture à tous les niveaux pour Infra : vérifier NFR (perfs, robustesse, sécu) et récupérer éléments pour sizing A: ça marche, bonne réunions en tous cas => processus itératif [Next slide]
- A: passons à la conclusion et la synthèse de tout ce que nous venons de faire ensemble
- A Bien collecter et tracer toutes les exigences avant de foncer tête baissée Attitude : ouverture d’esprit, se faire challenger par les pairs et les retours d’expérience Adopter et partager une démarche et un formalisme
- R : en termes de démarche différentes vues pour différents acteurs + Documenter : ADR et C4 => Object vivant: cycle de vie, respect des principes structurants ou tracer leur évolution