Event Driven, qu'est-ce donc ?! Un nouveau buzzword ?
•
0 j'aime•9 vues
Présentée lors du DevFest Lille 2023
Recommandé
Recommandé
Contenu connexe
Similaire à Event Driven, qu'est-ce donc ?! Un nouveau buzzword ?
Similaire à Event Driven, qu'est-ce donc ?! Un nouveau buzzword ? (20)
Event Driven, qu'est-ce donc ?! Un nouveau buzzword ?
- 1. Event Driven, qu'est-ce donc ?! Un nouveau buzzword ? Céline LOUVET
- 2. Céline LOUVET Lead developer chez Shine Développeuse backend et architecture cloud Recherche de stabilité et de qualité @celine_louvet @celine_louvet@pouet.chapril.org https://celine.louvet.me
- 4. Cas réel
- 5. Cas réel
- 6. Cas réel Contracts Logiciel propriétaire. Centralise les informations liées au contrat et options souscrites (quota, date de renouvellement, etc).
- 7. Cas réel Users Centralise les infos liées à l’identité (id, email, nom, prénom, etc.) Appelé par quasiment tous les services ⇒ SPOF (Single Point Of Failure) A d’autres rôles divers (envoi d’email, SMS etc)
- 8. Cas réel Photos Gère tout ce qui est relatif aux photos
- 9. Cas réel Fournisseurs externes Existence de divers services externes, avec des redondances.
- 10. Cas réel
- 11. Cas réel Photos de Pixabay L’utilisateur veut pouvoir, via son application mobile, afficher sa liste de photos. 1er besoin
- 12. Cas réel Photos de Pixabay L’utilisateur veut pouvoir, via son application mobile, partager une photo par email à un ami. 2ème besoin
- 13. Cas réel L’utilisateur veut pouvoir, via son application mobile, uploader une photo. 3ème besoin Photos de Pixabay
- 14. Fondamentaux
- 17. La théorie Fondamentaux - Traitements synchrones Pourquoi faire ça ? Pour obtenir la réponse pour poursuivre le traitement. Définition
- 18. La théorie Fondamentaux - Traitements synchrones Avantages Le résultat obtenu est à jour. La certitude que l’action s'est bien terminée et sinon pouvoir gérer l’erreur. Définition
- 19. La théorie Fondamentaux - Traitements synchrones Inconvénients Pause de Service 1 est attente de la réponse de Service 2. Obligation de gérer les erreurs, dans Service 1, si Service 2 est indisponible ou en erreur. Définition
- 22. La théorie Fondamentaux - Traitements asynchrones Pourquoi faire ça ? Quand Service 1 n’a pas besoin de la réponse. Quand le traitement déclenché est long. Définition
- 23. La théorie Fondamentaux - Traitements asynchrones Avantages Pas de temps d’attente pour Service 1. Pas d’erreur de Service 2 à gérer dans Service 1, uniquement l’indisponibilité. Définition
- 24. La théorie Fondamentaux - Traitements asynchrones Inconvénients Aucune assurance du succès du traitement de Service 2. Service 1 doit gérer l’indisponibilité de Service 2. Définition
- 26. Cas réel Fondamentaux - Traitements synchrones Photos de Pixabay L’utilisateur veut pouvoir, via son application mobile, afficher sa liste de photos. Notre besoin ?
- 27. Cas réel Fondamentaux - Traitements synchrones Contraintes présentes 1. Contracts est la source des infos de contrats et des options souscrites 2. Users est le point d’accès à Contracts 3. L’accès à Photos dépend des options du contrat
- 29. Cas réel Fondamentaux - Traitements synchrones Questions qu’on peut se poser ● Que se passe-t-il si Users ne répond pas ou est surchargé ? ● Que se passe-t-il si Contracts ne répond pas ou est surchargé ? ● Que se passe-t-il si beaucoup d’utilisateurs affichent leurs photos ?
- 30. Cas réel Fondamentaux - Traitements synchrones Problèmes possibles ● Chaîne d’appels : ○ Temps de réponse cumulés ⇒ lenteur globale ressentie ○ Erreurs possibles à chaque “niveau” ○ Beaucoup d’appels ⇒ Surcharge en chaîne ● Dépendance entre les services ⇒ Déploiement d’évolutions potentiellement complexe
- 32. Cas réel Fondamentaux - Traitements synchrones Amélioration Photos va exposer un webhook Il sera appelé, à chaque changement de la vie du contrat : ● à sa création ● à chaque modification de celui-ci ou d’une option ● à sa suppression
- 36. Cas réel Fondamentaux - Traitements synchrones Limites ● Autant d’appels que de services nécessitant d’avoir les infos de contrat, ● Traitement de Users très long ⇒ erreurs possibles. Conséquences
- 38. Cas réel Fondamentaux - Traitements asynchrones Photos de Pixabay L’utilisateur veut pouvoir, via son application mobile, partager une photo par email à un ami. Notre besoin ?
- 40. Cas réel Fondamentaux - Traitements asynchrones Inconvénients ● Chaîne d’appels ● Photos est en attente ⇒ Écran figé Proposition
- 41. Cas réel Fondamentaux - Traitements asynchrones Questions qu’on peut se poser ● Est-ce utile d’attendre la confirmation d’envoi ? ● Que se passe-t-il si Users ne répond pas ou est surchargé ? ● Pourquoi Users s’occupe-t-il d’envoyer les emails ?
- 43. Cas réel Fondamentaux - Traitements asynchrones 1ère amélioration Extraire la logique d’envoi d’email de Users ⇒ Création d’un service Notifications ● Envoyer des emails ou des SMS ● S’occuper de la redondance en cas d’indisponibilité des fournisseurs externes
- 45. Cas réel Fondamentaux - Traitements asynchrones Avantages Moins de logique dans Users ⇒ Separation of concerns (SoC) 1ère amélioration
- 46. Cas réel Fondamentaux - Traitements asynchrones Inconvénients Photos et Notifications sont bloqués en attente de la suite du traitement. 1ère amélioration
- 47. Cas réel Fondamentaux - Traitements asynchrones 2ème amélioration Utilisation d’un déclenchement asynchrone
- 49. Cas réel Fondamentaux - Traitements asynchrones Avantages Photos n’a plus à attendre l’envoi ⇒ Écran réactif 2ème amélioration
- 50. Cas réel Fondamentaux - Traitements asynchrones Inconvénients ● Pas d’assurance de l’envoi pour Photos. ● Photos et Notifications restent dépendants ⇒ complexité de déploiement. ⇒ gestion de l’indisponibilité. ● Notifications très central ⇒ Plus d’envoi d’email en cas de surcharge. 2ème amélioration
- 51. Modèle « Message Queuing »
- 69. La théorie Modèle « Message Queuing » Pourquoi faire ça ? Séparation entre logique de déclenchement et logique de traitement ⇒ Gestion naturelle de la charge de Service 2
- 70. La théorie Modèle « Message Queuing » Avantages Découplage entre Service 1 et Service 2: ● Déploiements simplifiés ● Échanges structurés ● Gestion des erreurs
- 71. La théorie Modèle « Message Queuing » Inconvénients Service 1 et Service 2 ne sont plus couplés explicitement ⇒ Erreur de Service 2, si le message n’a pas le format espéré.
- 72. La théorie Modèle « Message Queuing » « Message Queuing » en résumé ● Consommation en « First In, First Out » ⇒ tri temporel naturel. ● En cas d’erreur de traitement, le message sera à nouveau disponible. ● En cas de trop nombreuses tentatives, le message ira en « dead letter ». ● Un message ne peut être consommé qu’une fois. ● Un message n’est traité que si un consommateur a été défini.
- 73. La théorie Modèle « Message Queuing » Exemples de cas fréquents d’utilisation ● Envoi d’email. ● Traitements très consommateurs en CPU. ● Traitements très longs. ● Répartition de charge entre plusieurs instances de traitement.
- 74. La théorie Modèle « Message Queuing » Quelques implémentations Open Source : ● Active MQ ● Artémis ● Rabbit MQ Google Cloud Platform : ● Cloud Tasks AWS : ● Simple Queue Service (SQS)
- 76. Cas réel Modèle « Message Queuing » Photos de Pixabay L’utilisateur veut pouvoir, via son application mobile, partager une photo par email à un ami. Notre besoin ?
- 80. Cas réel Modèle « Message Queuing » Amélioration Avantages ● Découplage des services ⇒ Photos ne sait pas qui envoie l’email ⇒ Notifications ne sait pas qui lui demande l’envoi ● Le message queue se charge des tentatives d’envoi ⇒ Promesse d’envoi faite à l’utilisateur.
- 81. Cas réel Modèle « Message Queuing » Amélioration Inconvénients Découplage des services ● Erreur de Notifications, si Photos ne respecte pas le contrat ● Photos ne sait pas quand l’envoi est fait
- 82. Modèle « publish / subscribe »
- 91. La théorie Modèle « publish / subscribe » Pourquoi faire ça ? Pouvoir diffuser une information, sans se préoccuper de qui elle intéresse.
- 92. La théorie Modèle « publish / subscribe » Avantages Découplage complet, à condition de respecter le format attendu. Diffusion large, sous la forme de « sujet de discussion ». Gestion des erreurs, par des tentatives.
- 93. La théorie Modèle « publish / subscribe » Inconvénients Le contenu du message doit être assez généraliste pour convenir à tous. Aucune assurance qu’un abonné a souscrit à un sujet.
- 95. La théorie Modèle « publish / subscribe » A noter Un statut de message par abonné au sujet ⇒ Possibilité de renvoyer un message à un abonné en cas d’erreur. Durée maximale de traitement définie lors de l’abonnement ⇒ Nécessaire au bus pour estimer un timeout.
- 96. La théorie Modèle « publish / subscribe » « Publish / Subscribe » en résumé ● Un message peut être reçu par plusieurs abonnés. ● Utilisé pour diffuser largement un message. ● En cas d’erreur de traitement d’un abonné, le message lui sera à nouveau transmis. ● En cas de trop nombreuses tentatives, le message peut aller en « dead letter ». ● Un message n’est reçu que si un abonné existe.
- 97. La théorie Modèle « publish / subscribe » Exemples de cas fréquents d’utilisation ● Envoi d’email. ● Agrégation pour les analyses de données métier. ● Domotique. ● Collaboration simultanée sur un document.
- 98. La théorie Modèle « publish / subscribe » Quelques implémentations Open Source : ● Apache Kafka Google Cloud Platform : ● Cloud PubSub AWS : ● Simple Notification Service (SNS)
- 100. Cas réel Modèle « publish / subscribe » Photos de Pixabay L’utilisateur veut pouvoir, via son application mobile, afficher sa liste de photos. 1er besoin
- 102. Cas réel Modèle « publish / subscribe » Contraintes présentes 1. Contracts est la source des infos de contrats et des options souscrites 2. Users est le point d’accès à Contracts 3. Photos et d’autres services ont besoin de ces informations
- 105. Cas réel Modèle « publish / subscribe » Amélioration Avantages Users n’a qu’un seul message à envoyer. C’est le rôle des abonnés de savoir ce qui les intéressent.
- 106. Cas réel Modèle « publish / subscribe » Amélioration Inconvénients Latence entre la création du contrat et la copie de Photos des options ⇒ Possible désynchronisation des données.
- 108. Cas réel Modèle « publish / subscribe » Photos de Pixabay L’utilisateur veut pouvoir, via son application mobile, partager une photo par email à un ami. 2ème besoin
- 110. Cas réel Modèle « publish / subscribe » Contraintes présentes 1. Notifications centralise l’envoi d’email ou SMS. 2. Plusieurs services peuvent vouloir envoyer des notifications. 3. Photos n’est pas prévenu du succès de l’envoi.
- 114. Cas réel Modèle « publish / subscribe » 1ère amélioration Avantages Un seul sujet pour les envois de notification. EventBus gère les erreurs ⇒ assurance de l’envoi.
- 115. Cas réel Modèle « publish / subscribe » 1ère amélioration Inconvénients L’utilisateur ne sait pas quand l’envoi sera fait.
- 119. Cas réel Modèle « publish / subscribe » 2ème amélioration Avantages L’utilisateur sait quand son envoi sera fait.
- 120. Cas réel Modèle « publish / subscribe » 2ème amélioration Inconvénients Complexité très supérieure: ● Communication à double sens, ● Abonnement / désabonnement dynamiques, ● Notification push à l’utilisateur. Abonnement dynamique n’est pas proposé par toutes les implémentations.
- 121. Cas réel Modèle « publish / subscribe » Questions qu’on peut se poser ● Est-ce que ça vaut vraiment le coût ?
- 122. Serverless
- 127. La théorie Serverless Pourquoi faire ça ? Ne démarrer une ressource que quand elle devient utile / nécessaire. ⇒ Souvent un besoin spécifique du cloud (gestion des coûts).
- 128. La théorie Serverless Avantages Diminution des coûts d’instance. Scalabilité naturelle.
- 129. La théorie Serverless Inconvénients Démarrage à froid (cold start) à chaque appel ⇒ Latence de traitement si l’applicatif est long à démarrer.
- 130. La théorie Serverless Différents types de Serverless Function: ● 1 appel = 1 instance ● Réaction à un événement ● Traitement plus unitaire / rapide Container: ● 1 instance = N appels ● Traitement plus complexe / rapide
- 131. La théorie Modèle « publish / subscribe » Exemples de cas d’utilisation fréquents Function: ● Upload d’un fichier dans un bucket ● Envoi d’un message ● Appel reçu sur un webhook Container: ● Génération d’un PDF ● Exposition d’une API
- 132. La théorie Serverless Quelques implémentations Open Source : ● Serverless ● OpenFaaS ● Kubeless Google Cloud Platform : ● Function: Cloud function ● Container: Cloud run AWS : ● Function: Lambda ● Container: Fargate
- 133. Serverless Cas réel
- 134. Cas réel Serverless L’utilisateur veut pouvoir, via son application mobile, uploader une photo. 3ème besoin Photos de Pixabay
- 139. Cas réel Serverless Proposition Avantages Scalabilité naturelle, en fonction du nombre de photos à redimensionner.
- 141. Conclusion
- 142. Conclusion Est-ce que vous en avez besoin ? ● Dépend du nombre d’utilisateurs ou d’appels reçus ● De la fluctuation entre pic creux et pic élevé ● Du degré de découplage recherché ● Du besoin de communication entre services
- 143. Conclusion Est-ce que vous en avez besoin ? Ça dépend !
- 144. Est-ce que Event Driven est un buzzword ?
- 146. Faites-moi un retour sur openfeedback.io ! recrute ! RDV sur careers.shine.fr