Werner Vogels, CTO Amazon.com, l’a clamé haut et fort lors de son discours d’ouverture d’AWS Re:Invent 2022 : « Le monde est asynchrone. Le monde est événementiel ».

En tant que conférence mondiale autour du cloud,Re:Invent est une étape annuelle cruciale pour vendre des idées, montrer des orientations technologiques, présenter des innovations. C’est précisément ce qu’a fait Dr Vogels en promouvant cette architecture asynchrone, base d’un cloud computing nouvelle génération.

Mais savez-vous précisément en quoi consiste une architecture pilotée par les événements ? Ses différences avec une API-driven architecture ? Ses avantages ?

Laissez-vous guider dans ce monde asynchrone !

Event-driven architecture : une approche nouvelle

En matière de développement d’applications modernes, une “event-drive architecture” – architecture pilotée par les événements – devient de plus en plus majoritaire, car elle facilite grandement la création de solutions sur le cloud.

Elle permet de découpler vos services, ce qui :

• augmente la productivité de vos développeurs,
• facilite le débogage des applications, 
• élimine le goulot d’étranglement qui se produit lorsque les fonctionnalités s’étendent à différentes équipes,
• permet aux équipes de progresser de manière plus indépendante.

Dans une architecture événementielle, votre façon de penser le fonctionnement d’une application change. Vous la considérez comme un système qui réagit à des événements provenant de votre application, mais également de l’extérieur.

Dans cette approche, vous vous concentrez sur l’interaction du système avec son environnement en tant que transmission d’événements. L’application reçoit et crée des événements. Les entrées de l’application et les sorties de l’application agissent aussi comme des événements.

API-driven architecture vs. event-driven architecture

Dans l’API-driven architecture, les composants d’une application communiquent via des appels d’API. Le client envoie une requête et attend une réponse avant d’effectuer la tâche suivante.

Dans une event-driven architecture, le client génère un événement et peut immédiatement passer à sa tâche suivante. Différentes parties de l’application répondent ensuite à l’événement selon les besoins.

Défis liés à l’API-driven architecture

Lors du démarrage d’une construction d’une nouvelle application, de nombreux développeurs utilisent par défaut une API-driven architecture. Elle peut intégrer étroitement des composants et ces composants communiquent via des appels synchrones.

Bien qu’une approche API driven soit souvent plus facile à démarrer, elle peut devenir difficile à mesure que votre application devient plus complexe. Voici un exemple dans le cadre d’une application e-commerce.

Une coordination étroite entre les microservices

Dans une application d’e-commerce typique qui utilise une API synchrone, le client fait une demande pour passer une commande et le service de commande envoie la demande en aval à un service de facturation. En cas de succès, le service de commande répond par un message de réussite ou un numéro de confirmation.

Dans cette phase initiale, il s’agit d’une connexion directe entre les deux services. Le défi survient lorsque vous ajoutez plus de services qui s’intègrent au service de commande.

Si vous ajoutez un service d’exécution et un service de prévision, le service de commande a plus de responsabilités et plus de complexité. Le service de commande doit savoir comment appeler l’API de chaque service, de la structure d’appel d’API à la sémantique de nouvelle tentative de l’API.

Gestion des erreurs et tentatives

Admettons que vous ajoutiez de nouveaux services en aval pour l’exécution et l’expédition des commandes à l’application de commerce électronique.

Dans le meilleur des cas, tout fonctionne comme prévu : le service de commande déclenche la facturation, les systèmes de paiement et met à jour les prévisions. Une fois le paiement effectué, cela déclenche l’exécution et l’emballage de la commande, puis informe le service d’expédition des informations de suivi.

Toutefois, si le centre de distribution ne peut pas trouver le produit parce qu’il est en rupture de stock, il se peut que le service de distribution doit alerter le service de facturation, puis annuler le paiement ou émettre un remboursement.

Si l’exécution échoue, le système qui déclenche l’expédition peut également échouer. Les prévisions doivent également être mises à jour pour refléter le changement. Ce flux de travail de correction vise uniquement à résoudre l’un des nombreux « chemins malheureux » potentiels qui peuvent survenir dans cette application de commerce électronique basée sur l’API.

Coordination étroite entre les équipes de développement

Dans une application intégrée de manière synchrone, les équipes doivent coordonner tous les nouveaux services ajoutés à l’application. Cela peut ralentir la capacité de chaque équipe de développement à publier de nouvelles fonctionnalités.

Imaginez : votre équipe travaille sur le service de paiement, on ne vous prévient pas qu’une autre équipe a ajouté un nouveau service de récompenses. Que se passe-t-il en cas d’erreur du service d’exécution ?

Votre équipe de paiement reçoit un message et vous annulez le paiement, mais vous ne savez peut-être pas qui gère les tentatives et la logique d’erreur. Si le service de récompenses change de fournisseur et a une nouvelle API, et n’en informe pas votre équipe, vous n’êtes peut-être pas au courant du nouveau service.

En fin de compte, il peut être difficile de coordonner ces orchestrations et flux de travail à mesure que les systèmes deviennent plus complexes et que la gestion ajoute plus de services. C’est l’une des raisons pour lesquelles il peut être avantageux de migrer vers une architecture pilotée par les événements.

Les avantages de l’event-driven architecture face à ces défis

L’architecture pilotée par les événements peut aider à résoudre les problèmes de coordination étroite des microservices, de gestion des erreurs et de tentatives, et de coordination entre les équipes de développement.

Une coordination étroite entre les microservices

Dans une architecture événementielle, l’éditeur émet un événement, qui est acquitté par le bus d’événements. Le bus d’événements achemine les événements vers les abonnés, qui traitent les événements avec une logique métier autonome. Il n’y a pas de communication directe entre les éditeurs et les abonnés.

Les applications découplées permettent aux équipes d’agir de manière plus indépendante.

Par exemple, avec une intégration basée sur l’API, si votre équipe souhaite être informée d’un changement qui s’est produit dans le microservice d’une autre équipe, vous devrez peut-être demander à cette équipe d’effectuer un appel d’API à votre service.

Par conséquent, vous devrez peut-être tenir compte de l’authentification, de la coordination avec l’autre équipe sur la structure de l’appel API. Cela provoque des allers-retours entre les équipes, ce qui ralentit le temps de développement. Avec une application pilotée par les événements, vous pouvez vous abonner aux événements envoyés depuis votre microservice et le bus d’événements (par exemple, Amazon EventBridge ) se charge d’acheminer l’événement et de gérer l’authentification.

Gestion des erreurs et tentatives

Une autre raison de migrer vers une architecture basée sur les événements est de gérer un trafic imprévisible. Les sites Web de commerce électronique comme Amazon.com ont des quantités de trafic variables selon le jour. Une fois que vous passez une commande, plusieurs choses se produisent.

Tout d’abord, Amazon vérifie votre carte de paiement pour s’assurer que les fonds sont disponibles. Ensuite, Amazon doit emballer la marchandise et la charger sur des camions. Tout cela se passe dans un centre de distribution Amazon. Il n’y a pas d’appel d’API synchrone pour le backend Amazon pour emballer et expédier les produits. Une fois que le système a confirmé votre paiement, le front rassemble des informations décrivant l’événement et place votre numéro de compte, les informations de votre carte de paiement et ce que vous avez acheté dans un événement packagé et le place dans le cloud et dans une file d’attente. Plus tard, un autre logiciel supprime l’événement de la file d’attente et démarre l’emballage et l’expédition.

Le point clé ici est que ces processus peuvent tous s’exécuter à des rythmes différents.

Améliorer la collaboration d’équipe

Les architectures pilotées par les événements favorisent l’indépendance de l’équipe de développement en raison du couplage lâche entre les éditeurs et les abonnés.

Les applications découplées vous permettent également de créer de nouvelles fonctionnalités plus rapidement.

L’ajout de nouvelles fonctionnalités ou l’extension de celles existantes peut être plus simple avec les architectures pilotées par les événements, car vous ajoutez de nouveaux événements ou modifiez ceux qui existent déjà. Ce processus supprime la complexité de votre application.

Conclusion

Lors de la création d’une solution sur le cloud, le choix entre une API-driven architecture et une Event-driven architecture est clairement stratégique. Même si la première semble plus simple car plus intégrée par les équipes, la seconde optimisera, à moyen et long terme, votre temps de développement et vos coûts. Il convient donc d’analyser vos objectifs business afin de ne pas choisir un modèle par défaut qui pourrait impacter votre expansion.

Si vous souhaitez être conseillé sur ce sujet, contactez l’équipe de Premaccess !

Nos cas clients et projets utilisant une « Event-driven Architecture »

Sources

• https://aws.amazon.com/fr/blogs/compute/getting-started-with-event-driven-architecture/
• https://aws.amazon.com/fr/blogs/compute/benefits-of-migrating-to-event-driven-architecture/
• https://sbrisals.medium.com/aws-re-invent-2022-my-seasonal-highlights-e70d8efd219d
• https://dashbird.io/blog/building-complex-well-architected-serverless-architectures/