[RVD24]Apprenons à identifier les exigences techniques pour mieux concevoir

Avez-vous déjà entendu "ça doit fonctionner 24/7", "Je veux 100% de dispo", pour finir avec "en réalité, une VM ça sera largement suffisant" ?
Ou au contraire "Pas de SLA, ma plateforme n'est pas critique, il faut juste qu'elle tourne impérativement le premier du mois à 6h54 précises" ?

Si ces situations sont votre quotidien, ne perdez pas espoir ! Que ces critères techniques (Non Functional Requirements) soient explicites ou non, ils sont la clé qui vous permettra de concevoir une architecture en adéquation avec le besoin client.

En se basant sur deux exemples fictifs (toute ressemblance avec la réalité serait bien évidemment fortuite, ou pas), nous verrons comment déjouer les pièges de la surqualité, et comment mettre en place une démarche pragmatique d'identification de la bonne architecture pour le bon besoin métier.

À l’issue de cette présentation, nous saurons comment identifier ces fameuses NFRs qui nous aiderons à concevoir de meilleures architectures en évitant la sur-complexité !

Transcript

1. Apprenons à identifier les exigences techniques pour mieux concevoir Philippe DUVAL / Alexandre TOURET
2. 69% Source: Standish group Chaos report 2020
4. ❑1 million d’ utilisateurs enregistrés mais peu actifs ❑500Go de données ❑50 TPS (en pic) ❑40 millions d’utilisateurs actifs ❑40To de stockage sécurisé ❑1200TPS Référentiel de données sensibles Objectifs donnés par le client Après 2 ans…
7. Vous êtes le n°1,492,573 dans la file d’attente
8. En coulisse… Ça ne tient pas la charge Pas disponible Ça a encore planté La base de données est en train de mourir Les temps d’attente sont trop longs Ça rame l'archi ne scale pas
10. ❑ Comprendre les exigences techniques du client ❑ Produire la conception la plus simple possible ❑ Adapter les coûts de la conception à la valeur métier Comment faire partie des 31%?... →Ne pas s’arrêter aux besoins fonctionnels!
11. Dispo 24/7 et au-delà Dispo « On ne sait pas » Deux applications
12. Alexandre TOURET Architecte Logiciel @touret_alex blog.touret.info Philippe DUVAL Architecte Cloud @malkav30 malkav30.gitlab.io Qui sommes-nous?
13. 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
14. Quelques définitions
15. Volumétrie Temps de réponse Quantité de données Requêtes par seconde
16. ❑ Objectifs de qualité de service INTERNES 99% des pages Web doivent être affichées en moins de 2 sec Service Level Objective ❑ Mesure la conformité d’une SLO Mesure effective du temps d’affichage à partir du serveur HTTP Service Level Indicator ❑ Valeur contractuelle (SLA < SLO) Service Level Agreement SLO/SLI/SLA ? ngular ro ides eb pa es ac end ro ides A s e customer o uses our application
17. Disponibilité T p ’ p (temps par an) 90% 36 jours, 14 heures et 24 minutes 95% 18 jours, 6 heures et 2 minutes 99% 3 jours, 15 heures et 36 minutes 99,9% 8 heures, 45 minutes et 36 secondes 99,95% 4 heures, 22 minutes et 56 secondes ❑ Capacité d'une application à être opérationnelle et accessible aux utilisateurs lorsqu'ils en ont besoin (ex. 99%) ❑ Elle peut être limitée dans le temps (ex. de 8H à 20H) Disponibilité & ouverture(s) de services
18. ❑ Que fait-on quand us-east-1 est down? Disaster Recovery Site ❑ Objectifs de temps de reprise en cas d'incident Le service doit être rétabli en 1h Recovery Time Objective ❑ Quelle quantité de données accepte-t-on de perdre? Les commandes des 5 dernières minutes Recovery Point Objective RTO/RPO, DRS ?
19. The F in ISO 25000 stands for Fun
20. Application #1: Une application disponible 24/7 et au-delà
21. ✓ Prise de commande ✓ Paiement « CETTE APPLICATION NE DOIT JAMAIS PLANTER, DISPO 24/7 100% DU TEMPS » Application disponible 24/7, eleven nines Inc.
24. Service SLA App Engine 99,95% Spanner 99,99%
25. Le besoin réel...
27. Service SLA Cloud Run 99,95% Cloud SQL ?%
28. ❑Cloud SQL • 24/7, Instance db-standard-2 • Stockage 10.0 GiB • EUR 38.65 ❑Cloud Run • CPU à la requête, 2 CPU 1GiB • Memory: 1 GiB • 5/7, 11h-22h, 5,000 commandes/mois • EUR 0.00 ❑Cloud Spanner • 100 processing units: 100 • Stockage 10 GiB • Backup 10 GiB • EUR 72.90 ❑App Engine standard instances • 24/7, Instance F4_1G x 4 • EUR 752.91 Impacts financiers EUR 825,81 EUR 38,65
29. Application #2 : « On ne sait pas »
30. Une charcuterie en ligne Description du besoin : « Une application de e-commerce pour la livraison à domicile de produits régionaux » Autrice: Aurélie Vache ©
32. L’arc itecture (V1) Ama on A ate a A S Lambda Ama on D namoD Ama on S A S Lambda A S af a lient 1 2 4 5
34. https://www.primevideotech.com/video-streaming/scaling-up-the-prime- video-audio-video-monitoring-service-and-reducing-costs-by-90
35. L’arc itecture (V2) Ama on A ate a A S E 2 Ama on D namoD Ama on S lient 1 2 4
36. Pourquoi ces échecs?
37. ❑Les NFRs n’étaient pas adaptées au modèle économique ❑L’application n’a ait pas pris en compte le coût dans la recherche de scalabilité ❑Les NFRs n’ étaient pas alignées avec le métier Pourquoi ces applications peuvent faire partie des 69% ? OK, améliorons tout ça !
38. Notre approche
39. Connaître et comprendre les exigences métier Objectifs techniques Connaître l’exploitation Evaluer les risques Répondre à la question « Est-ce que ça vaut la peine ? » La démarche
40. Connaître et comprendre les exigences métier Objectifs techniques Connaître l’exploitation Evaluer les risques Répondre à la question « Est-ce que ça vaut la peine ? »
41. HIPAA Certains NFRs iennent en bande… HDS KRITIS PSD2 PCI-DSS CERD OIV
42. Et si l’application #1 était un O V?
45. Service SLA GKE Multi-Région 99,99% Spanner Multi-Région 99,999%
46. Exigences métier
49. Connaître et comprendre les exigences métier Objectifs techniques Connaître l’exploitation Evaluer les risques Répondre à la question « Est-ce que ça vaut la peine ? »
50. Objectifs techniques Ne prenez aucune contrainte technique pour acquise!
51. rincipales caractéristiques d’une arc itecture Évolutivité Modularité Coût Performance Simplicité Testabilité Résilience & Tolérance aux pannes
52. Architectures évolutives
53. Résilience
54. Haute Disponibilité Auto Remédiation Nouveau paradigme De « Hope it will never happen » à « recover easily »
55. De quoi parle-t- q év q é ’ g ? Théorèmes CAP / PACELC
56. Logiciel Résilient = Deux problèmes vs
57. Timeouts “Eviter de saturer les ressources / éviter d’attendre éternellement” Circuit breakers “N’appelez pas les abonné absents” Graceful degradation “Que reste-t-il de mon MVP” Comment mitiger les problèmes de latence ? Retentatives “Mitiger l’indisponibilité intermittente” Exponentional Backoff “Eviter l’effet domino”
58. Connaître et comprendre les exigences métier Objectifs techniques Connaître l’exploitation Evaluer les risques Répondre à la question « Est-ce que ça vaut la peine ? »
59. ’est une capacité de la plate-forme plus qu’un assembla e d’outils… Observabilité Exemple : architecture d’observabilité sur un gros projet
60. Adapter la compétence des équipes aux choix technologiques Opérabilité
61. Connaître et comprendre les exigences métier Objectifs techniques Connaître l’exploitation Evaluer les risques Répondre à la question « Est-ce que ça vaut la peine ? »
62. Les risques Source: riskstorming.com
63. Low 1 Medium 2 High 3 Low 1 Medium 2 High 3 - Database access issue Probability Impact
64. Low 1 Medium 2 High 3 Low 1 Medium 2 High 3 - Database access issue Probability Impact
65. ud et d’erreur
66. Connaître et comprendre les exigences métier Objectifs techniques Connaître l’exploitation Evaluer les risques Répondre à la question « Est-ce que ça vaut la peine ? »
67. « Est-ce que la fabrication de rillettes nécessite une disponibilité de 99.95%? » « Est-ce que l’application mobile est indispensable pour commander un Kebab? » Est-ce que ça en vaut la peine?
68. Conclusion
69. ❑ Avoir des objectifs techniques clairs et adaptés ❑Une évaluation pragmatique des risques à traiter ❑Simplicité et évolutivité Qu’a pu apporter notre approche ?
70. Si ous a e un existant… Impliquez les Ops Collectez, identifiez et qualifiez les différents risques Créez une base de connaissances
71. En résumé Creuser le besoin Identifier les exigences Simplifiez ! Itérez!
73. Don’t be a stran er! Follow & get in touch @malkav30 linkedin.com/in /phduval blog.worldline.tech @WorldlineTech Feedback Follow us: @touret_alex linkedin.com/in /atouret 73 | Follow our tech team:
74. Explore our jobs in tech: careers.worldline.com Want to shape how the world pays and get paid?