[TNT24] 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 ❑500Mo 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…
5. ❑ Elles ne sont pas “claires” ❑ Trop complexes par rapport aux besoins réels Exigences ❑ Risques techniques ❑ Risques humains Mauvaise gestion des risques Les raisons
7. You are user #1,492,573 in the waiting queue
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. ❑ Objectifs de qualité de service INTERNE 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 ? gu ar ro ides eb pa es ac e d ro ides A s e customer o uses our application
16. 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
17. ❑ 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 Que fait-on quand us-east-1 est down? Disaster Recovery Site RTO/RPO, DRS ?
18. Volumétrie Temps de réponse Quantité de données requêtes par seconde
19. Application #1: Une application disponible 24/7 et au-delà
20. ✓ Prise de commande ✓ Paiement « CETTE APPLICATION NE DOIT JAMAIS PLANTER, 24/7 100% DU TEMPS » Application disponible 24/7, eleven nines Inc.
23. Service SLA App Engine 99,95% Spanner 99,99%
24. Le besoin réel...
26. Service SLA Cloud Run 99,95% Cloud SQL ?%
27. ❑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
28. Application #2 : « On ne sait pas »
29. Une charcuterie en ligne Description du besoin : « Une application de e-commerce pour la livraison à domicile de produits régionaux » Autrice: Aurélie Vache ©
31. 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
33. https://www.primevideotech.com/video-streaming/scaling-up-the-prime- video-audio-video-monitoring-service-and-reducing-costs-by-90
34. L’arc itecture (V2) Ama on A ate a A S E 2 Ama on D namoD Ama on S lient 1 2 4
35. Pourquoi ces échecs?
36. ❑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 !
37. Notre approche
38. 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
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 ? »
40. • Activité indispensable à la survie de la nation • Nécessite une forte résilience (ex. aucun impact sur le service suite à un tremblement de terre) Opérateur d’ Importance Vitale • Forte exigence en termes de chiffrement Hébergement de Données de Santé Payment Card Industry Data Security Standard OIV, HDS, PCI
41. Et si l’application #1 était un O V?
44. Service SLA GKE Multi-Région 99,99% Spanner Multi-Région 99,999%
45. Exigences métier
48. 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 ? »
49. Objectifs techniques Ne prenez aucune contrainte technique pour acquise!
50. rincipales caractéristiques d’une arc itecture Évolutivité Modularité Coût Performance Simplicité Testabilité Résilience & Tolérance aux pannes
51. Architectures évolutives
52. Résilience
53. Haute Disponibilité Auto Remédiation Nouveau paradigme De « Hope it will never happen » à « recover easily »
54. De quoi parle-t- q év q é ’ g ? Théorèmes CAP / PACELC
55. Logiciel Résilient = Deux problèmes vs
56. Timeouts “éviter de saturer les ressources / éviter d’atte dre éter e eme t” Circuit breakers “ ’appe ez pas es abo és abse ts” Graceful degradation “que reste-t-i de mo MVP” Comment mitiger les problèmes de latence ? Retentatives “Mitiger ’i dispo ibi ité i termitte te” Exponentional Backoff “éviter ’effet domi o”
57. 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 ? »
58. ’est une capacité de la plate-forme plus qu’un assembla e d’outils… Observabilité Exemp e : architecture d’observabi ité sur u gros projet
59. Adapter la compétence des équipes aux choix technologiques Opérabilité
60. 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 ? »
61. Les risques Source: riskstorming.com
62. Low 1 Medium 2 High 3 Low 1 Medium 2 High 3 - Erreur d'accès à la database Probability Impact
63. ud et d’erreur
64. 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 ? »
65. « Est-ce que la fabrication de rillettes nécessite une disponibilité de 99.95%? » « Est-ce que ’app icatio mobi e est indispensable pour commander un Kebab? » Est-ce que ça en vaut la peine?
66. Conclusion
67. ❑ Avoir des objectifs techniques clairs et adaptés ❑Une évaluation pragmatique des risques à traiter ❑Simplicité et évolutivité Qu’a pu apporter notre approche ?
68. Si ous a e un existant… Impliquez les Ops Collectez, identifiez et qualifiez les différents risques Créez une base de connaissances
69. En résumé Creuser le besoin Identifier les exigences Simplifiez ! Itérez!
71. 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 71 | Follow our tech team:
72. Explore our jobs in tech: careers.worldline.com Want to shape how the world pays and get paid?