Anúncio
Anúncio

Mais conteúdo relacionado

Similar a [TADx] 1 plateforme à convevoir, 2 architectes : 3 possibilités ?(20)

Anúncio

[TADx] 1 plateforme à convevoir, 2 architectes : 3 possibilités ?

  1. TADx 1 plateforme à concevoir 2 architectes 3 possibilités Raphaël SEMETEYS - Alexandre TOURET
  2. Alexandre TOURET Architectelogiciel @touret_alex blog.touret.info Raphaël SEMETEYS Architectelogiciel @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 arewe? 3 | @worldlinetech
  4. 4
  5. Vue métier 5
  6. 6
  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,RecoveryPoint 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ésurles pics • Capacité à intégrer facilementdes 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 formaliserles 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
  33. 33
  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émentré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 |
Anúncio