Architectures réactives : quels rôles respectifs pour les API et l’architecture événementielle ?

Architectures réactives : quels rôles respectifs pour les API et l’architecture événementielle ?

Les architectures réactives (tels que définis par le Manifeste Réactif) sont un ensemble de principes de conception architecturale pour la construction de systèmes réactifs bien préparés pour répondre aux enjeux auxquels les applications sont confrontées aujourd’hui. Auparavant, une application se contentait de communiquer avec une seule base de données. Aujourd’hui, elle doit composer avec des sources de données de natures hétérogènes : SQL, NoSQL, APIs, Webservices…

Le fondement d’un système réactif est le passage de messages, qui crée une frontière temporelle entre les composants permettant leur découplage dans le temps (ce qui permet la concurrence) et dans l’espace (ce qui permet la distribution et la mobilité). Ce découplage est une condition nécessaire à l’isolation complète entre les composants et constitue la base de la résilience et de la souplesse du système.

1.     Passage d’une logique application à une logique système – pilotage par des messages

Les systèmes que nous créons aujourd’hui doivent être multi-devices, à proximité ou à l’autre bout du monde. Et en parallèle, les utilisateurs sont de plus en plus exigeants quant à la disponibilité des systèmes et leurs fonctionnements sans heurts. Les systèmes doivent être réactifs, car il importe peu que quelque chose fournisse la bonne réponse si celle-ci n’est pas disponible lorsqu’elle est nécessaire. Pour y parvenir, nous devons nous assurer que la réactivité est au rendez-vous (résilience) même avec une charge fluctuante et dynamique (élasticité). Pour ce faire, il faut piloter ces systèmes par des messages et cela constitue un point structurant d’une architecture réactive.

2.     Notre point de vue sur l’architecture réactive

Nos anciens modèles d’architecture n’étaient tout simplement pas conçus pour faire face au monde changeant des données dans lequel nous vivons et aux énormes fluctuations de la charge de nos systèmes. Mais la réactivité n’est pas pour tout le monde, tout comme les micro-services ne sont pas la réponse à la modernisation de toutes les applications.

Si votre application traite de vastes volumes de données et que vous souhaitez que votre système reste réactif et fournisse la même qualité de service à chaque utilisateur, quelles que soient les variations de charge, l’architecture réactive mérite assurément d’être envisagée.

a.  Les bénéfices constatés au cours de nos prestations

  • Une amélioration de la résilience grâce à un découplage de la gestion des pannes de la chaîne d’appel, en libérant le client de la responsabilité de la gestion des pannes serveurs.
  • Une plus grande Elasticité du système grâce à la capacité à mettre le système à l’échelle de la même manière, en utilisant les mêmes abstractions de programmation, avec la même sémantique, dans toutes les dimensions de l’échelle (depuis les cœurs de CPU aux datacenters)
  • Les systèmes réactifs représentent l’architecture la plus productive que nous connaissons et nous faisons le choix très volontaire de vous exposer nos convictions.

b.  Les limites rencontrées

  • La mise en place d’architecture réactive est complexe, ajoute des niveaux d’abstractions et vous mettra à l’épreuve avec des défis qui ne seront pas facile à relever.
  • Les architectures réactives sont des architectures adaptées pour le traitement des flux de données. Nous n’avons remarqué aucun gain à mettre en place une architecture de ce genre pour une application classique.

3.     L’architecture événementielle et l’architecture réactive – deux approches complémentaires

La principale différence entre une architecture réactive et une architecture événementielle est que les messages de l’architecture réactive sont dirigés de manière inhérente, alors que les événements ne le sont pas. Les messages ont une destination claire et unique, tandis que les événements sont des faits que les autres doivent observer.

Nous avons tous déjà envoyé des événements à l’intérieur de messages sur le réseau tout simplement parce que cela permet de maintenir la simplicité relative du modèle de programmation événementielle dans un environnement distribué (AWS Lambda, Spark Streaming, Flink, Kafka et Akka…). Cependant, il y a un compromis à faire : ce que l’on gagne en abstraction et en simplicité du modèle de programmation, on perd en termes de contrôle.

L’architecture réactive nous oblige à accepter la réalité et les contraintes des systèmes distribués comme par exemple les défaillances partielles, la détection des pannes, les messages perdus…

Dans un système construit sur les principes d’architecture réactive, les briques événementielles et de gestion de messages sont tous deux biens présents mais utilisés de manière complémentaire : l’un est un excellent outil de communication (messages) et l’autre est un excellent moyen de représenter des faits (événements).

4.     Les architectures orientée services bénéficierait à adopter les principes de l’architecture réactive

Pour la plupart de nos clients, un élément essentiel pour devenir une entreprise cognitive est de migrer vers une infrastructure cloud hybride et d’adopter une architecture micro-services. La combinaison de cette approche avec les méthodologies DevOps telles que l’intégration continue, la livraison continue et le déploiement continu peut conduire à des gains d’efficacité considérables.

De notre point de vue, nous pourrions monter d’un cran concernant ces systèmes basés sur des architectures orientées services qui bénéficieraient beaucoup par l’adoption de principes de l’architecture réactive.

Généralement, quand le use case est valorisant pour nos clients, nous les orientons vers l’utilisation des principes du « Reactive Manisfesto » entre les micro-services permettant la création de systèmes réactifs de micro-services. Cela permet d’améliorer la résilience et la souplesse du SI dû au fait que ces systèmes sont pilotés par des messages. Par exemple, les échanges de messages asynchrones non bloquants nous permettent de découpler les micro-services en temps et en heure. Plus concrètement, cela signifie que les services ne dépendent pas de la réponse des uns et des autres. Si une demande adressée à un service échoue, l’échec ne se propagera pas. Le service client peut continuer à fonctionner sans attendre la réponse. Et c’est la grande forme d’allier les deux approches.

Lors de nos interventions, nous nous sommes rendu compte que plusieurs prérequis étaient nécessaires pour adopter pleinement les bénéfices d’une architecture orientée services « réactive » :

  • Définir les limites des services à faire une chose mais une chose bien
  • Isoler les services et veiller à ce que les services agissent de manière autonome
  • Adopter le passage asynchrone des messages

Conclusion

Notre positionnement est clair : l’architecture réactive est l’objectif à atteindre et les APIs (plus précisément les architectures orientées services) et les pratiques d’architectures event-driven ne sont pas obsolètes mais plutôt des accélérateurs pour atteindre cet objectif.

 



Laisser un commentaire