Point de vue sur les architectures microservices event-driven

Share this post:

Cet article a été rédigé avec le concours d’Olivier Barrot, Vincent Baruchello, Xiaohua Le et Laurent Sene.

Pourquoi considérer les architectures event-driven ?

L’essor et le développement du Cloud, l’utilisation de conteneurs, et la montée en puissance de « Pizza teams » agiles qui travaillent sur des composants de petite taille, ont conduit à une évolution des architectures applicatives vers des architectures de microservices « Cloud natives ».

La fragmentation des monolithes en microservices permet d’avoir des services indépendants et autonomes, avec un modèle architectural qui supporte mieux l’élasticité et est plus adapté aux développements agiles.
Cette fragmentation entraîne toutefois une augmentation de la combinaison des invocations entre ces services (trafic Est-Ouest).
Se pose alors la question du modèle d’invocation à adopter entre ces microservices :

• Appels synchrones basés sur des API REST
  Les invocations synchrones sont bien connues et maîtrisées par les équipes de développement et les architectes, mais elles limitent l’élasticité et l’évolutivité des services qui ne sont pas totalement autonomes. C’est pourquoi, lorsqu’un problème survient les défaillances s’enchaînent en cascade.
  Ces inconvénients sont partiellement résolus par un framework de Service Mesh. Basé sur l’utilisation d’API REST et le pattern « side-car proxy » (dont les implémentations les plus populaires sont Istio et Linkerd), le Service Mesh permet d’externaliser les règles et les politiques de routage des appels entre microservices et augmente leur autonomie.

• Appels asynchrones basés sur un modèle événementiel.
  Dans ce modèle, tous les appels entre services se font de manière asynchrone, ce qui permet de découpler les microservices, offre plus de résilience et d’élasticité puisque chaque microservice devient complètement autonome.
  Un broker de messages Publish/Subscribe est requis. Kafka étant la solution qui s’est imposée sur le marché, c’est celui sur lequel sera développé le reste de cette publication.

Ces deux modèles d’invocations ne sont pas exclusifs, l’utilisation d’API peut évidemment coexister avec un modèle de messaging et même une architecture event-driven.

L’event-driven est plus qu’un modèle de communication asynchrone

L’EDA (Event Driven Architecture) est un paradigme de conception d’applications qui est bien plus qu’un simple modèle de communication asynchrone entre applications.

Les appels asynchrones entre services sont toujours une bonne idée lorsqu’ils sont fonctionnellement adaptés. Cependant, ce n’est pas parce que vous avez des services faiblement couplés à l’aide d’appels asynchrones que vous avez fait de l’EDA.

Une architecture event-driven repose sur le fait que les données échangées entre les services sont des événements qui notifient des faits métiers importants qui se sont produits, et qui correspondent la plupart du temps à des objets métiers.

Avantages de l’architecture event-driven

L’architecture event-driven (que l’on rencontre également sous les noms Event Streaming ou architecture réactive) apporte de nombreux avantages :

• Le couplage lâche des microservices favorise l’autonomie des microservices, et offre une plus grande résilience. En cas de panne d’un microservice, les appels API ne restent bloqués en attente d’une réponse.
• C’est une architecture élastique qui est parfaitement adaptée au serverless, avec des microservices qui sont instanciés uniquement lorsqu’il y a un message à consommer.
• Le couplage lâche entre le producteur et le consommateur de messages facilite la scalabilité. Chaque microservice est mis à l’échelle en fonction de ses propres besoins.
  C’est ce type d’architecture qui permet à LinkedIn de gérer 1,4 milliards de messages par jour et deux pétaoctets de données chaque semaine.
• L’EDA facilite la gestion des défaillances en cascade (cascading failures) résultant des interdépendances de microservices. La défaillance d’un microservice ne se propage pas aux autres et permet une approche « Design for failure » pour des solutions « Always On ».
• Un système basé sur les principes de l’architecture orienté événements est évolutif et extensible par conception. Il est possible par exemple de créer à tout moment un nouveau service pour réagir à un événement sans aucun impact sur les services existants.
• Un système d’information basé sur l’EDA est naturellement orienté temps (quasi) réel. Les flux batchs traditionnels peuvent être remplacés dans certains cas par le streaming d’événements, et permettre ainsi de procéder à des traitements analytiques temps (quasi) réel.
• Enfin, les architectures événementielles permettent un meilleur partage des données. La grande majorité des entreprises ont aujourd’hui placé la donnée au centre de leur stratégie. L’approche événementielle favorise la production de données et elle est par nature data-centric.
  En effet, les événements échangés sont des données en mouvement, qui ne sont plus uniquement détenues par des applications propriétaires, mais deviennent aisément consommables.
  On se rapproche du concept de produits de données, l’un des principes clés des architectures data-mesh.

Les principes des architectures event-driven

Voici un exemple extrêmement simplifié illustrant l’architecture d’une application développée selon les principes de l’EDA.
Cette application prend des commandes de produits (un cas d’utilisation très simplifiée, sans contrôle dans le référentiel d’un client, ni dans le référentiel d’un produit) et envoie la commande à l’entrepôt qui effectuera l’expédition. Un administrateur de site Web surveille les commandes avec une vue 360.

L’application est composée de 4 microservices :

• Deux services Command différents (le « C » de CQRS) permettent d’enregistrer des Clients et des Commandes depuis une interface graphique (la partie GUI n’est pas représentée ici).
• Un service de Query (le « Q » de CQRS), permet aux administrateurs d’effectuer des recherches sur l’historique des commandes.
• Un processeur d’événements « Order Shipping », effectue une jointure entre les topics Client et Commande, avant de publier un événement qui déclenche l’expédition depuis l’entrepôt des produits.

Caractéristiques et défis des applications EDA

Les architectures Event Driven présentent certaines caractéristiques qui leur sont bien spécifiques, ainsi que des difficultés, parfois inédites, à relever.

Certaines de ces spécificités ont été identifiées ci-dessous et cette liste n’est sans doute pas exhaustive. Vous trouverez des informations détaillées sur ces sujets, les problématiques soulevées et des pistes de remédiation dans le document complet à venir très prochainement : TEC-F – Event Driven Architectures.pdf.

IBM Event Automation

Apache Kafka est la solution la plus populaire utilisée pour implémenter les applications EDA, et est en mesure de gérer des milliards d’événements par jour. Depuis sa création en open source en 2011, Kafka s’est quasiment imposé comme un standard de l’industrie.
L’écosystème Kafka est riche, nous nous contenterons dans cette publication de présenter sommairement la solution IBM.

IBM Event Automation est un produit lancé en mai 2023. Il s’agit d’une solution de traitement d’événements composée d’un ensemble d’outils visuels, intuitifs et intégrés.
IBM Event Automation permet de distribuer, découvrir, socialiser, transformer et gérer des événements.

IBM Event Automation adopte une approche communautaire open source basée sur Kafka et Flink, et fourni un ensemble de fonctionnalités intégrées qui accélèrent la mise en œuvre d’applications event-driven :

• Distribution d’événements, basée sur Kafka qui prend en charge les schémas de données d’événement, permet l’équilibrage de la charge de travail et fournit des connecteurs pour accéder aux systèmes externes.
• Découverte d’événements, grâce au portail de socialisation qui rend les événements accessibles et permet la découverte et la consommation d’événements, en gérant les sources d’événements pour les réutiliser en toute sécurité dans toute l’entreprise.
  IBM Event Automation permet de décrire les flux d’événements de manière standardisée au format AsyncAPI, et de les publier dans un catalogue consultable en accès self-service.
• Processing d’événements, qui s’appuie sur Flink pour filtrer, transformer et combiner et analyser les événements.

Le parcours d’adoption de l’EDA et les méthodologies

Dans le contexte de la transformation cloud, l’adoption d’une architecture event-driven nécessite une transformation importante en termes de technologie, mais aussi en termes de compétences et même d’organisation.

En effet, l’approche EDA est extrêmement disruptive sur un certain nombre de points :

• Expérience utilisateur de type « fire and forget »
• Architecture EDA
• Compétences en développement
• Méthodologies plus spécifiquement adaptées comme l’Event Storming
• Organisation et gouvernance

La dimension disruptive de l’EDA est probablement le principal obstacle limitant l’adoption et le développement de ce type d’architecture.

La figure ci-dessous illustre le parcours de transformation d’une entreprise pour atteindre la maturité nécessaire :

• L’étape du camp de base est celle de la transformation nécessaire pour l’adoption des microservices « Cloud native » traditionnels, basés sur des invocations d’API en direct.
• Un effort modéré supplémentaire est requis pour fournir des applications en mode service-mesh (mise en œuvre d’un side-car proxy au moyen d’un framework tel que Istio).
• L’effort de transformation supplémentaire nécessaire pour les applications orientées événements est plus conséquent.

La face nord du défi de l’adoption des architectures event-driven

Les cas d’usages les plus pertinents

En raison de son caractère disruptif, transformer l’ensemble de l’informatique d’une entreprise avec une approche EDA constitue un risque aujourd’hui. On peut cependant, distinguer certains cas d’usages en particulier.
Voici les cas d’utilisation les plus courants que nous avons rencontrés dans les entreprises :

1. Création de pipelines de données temps réel afin d’alimenter des data warehouse analytiques ou des lacs de données (analyse en continu).
2. Les applications de Complex Event Processing, et plus généralement tous les traitements basés sur une fenêtre temporelle.
3. Dans les secteurs industriels, l’IoT pour la gestion des flux de messages des devices est un bon candidat aux architectures event-driven.
4. Les applications réactives et la programmation asynchrone, avec des langages comme Vert.X par exemple.

Conclusion… EDA ou pas ? Telle est la question

Pour certains cas d’usages tels que les applications de Complex Event Processing, la question ne se pose pas et l’architecture événementielle s’impose naturellement.

Au-delà de ce cas d’usage, et lorsque le fonctionnel le permet, il est toujours recommandé de privilégier les communications asynchrones entre domaines, applications ou services plutôt que des invocations requête / réponse synchrones. Le couplage lâche offre de nombreux avantages, en particulier du point de vue de la résilience et de la tolérance aux pannes.

Les architectures orientés événements constituent donc un paradigme parfaitement adapté au développement d’applications cloud natives et plus particulièrement serverless qui réagissent aux événements. Il est donc intéressant d’intégrer l’adoption des architectures orientés événements dans la stratégie des entreprises.

L’architecture EDA est cependant disruptive et nécessite une approche différente à tous les niveaux : aussi bien en termes d’expérience utilisateur, que de conception, de développement ou d’exploitation. L’adoption de ces architectures peut être difficile, en particulier pour les entreprises qui n’ont pas une maturité suffisante sur les architectures cloud natives.

Il est par conséquent difficile de fournir à ce stade une préconisation générale, d’autant plus que les architectures service-mesh offrent déjà un certain niveau d’autonomie aux microservices. Nous pensons néanmoins qu’il reste judicieux d’explorer ce paradigme architectural et de tirer parti de tous les avantages offerts.

Une approche innovante mais prudente, peut consister à explorer des architectures événementielles sur un cas d’usage limité dans un premier temps, sans engager l’entreprise dans une transformation à grande échelle. Le cas d’utilisation du pipeline de données temps-réel pour alimenter un warehouse ou un lac de données, dans l’objectif de faire des traitements analytiques temps-réel est sans doute la première étape la plus simple à réaliser.

Une généralisation de l’usage des architectures event-driven pourra ensuite être envisagée ultérieurement, au rythme de la montée en compétence des équipes.