Avez-vous entendu parler du Reactive Manifesto?
L’explosion des données, mais aussi la pression des clients qui demandent de plus en plus de Temps Réel a conduit les équipes IT à revoir leur façon de concevoir leurs applications et leurs logiciels.
C’est dans ce contexte qu’a été rédigé le Reactive Manifesto (ou Manifeste Réactif en Français) qui fournit les principes des Architectures Réactives.
En voici un petit résumé.
Les principes du Reactive Manifesto
Le manifeste a vocation a définir les bases de l’architecture des applications logicielles modernes.
Selon le Reactive Manifesto, les systèmes réactifs doivent être :
- Disponibles
- Résilients
- Souples
- Orientés Messages
Et ces 4 éléments sont intimement liés !
Principe #1 : la disponibilité du reactive manifesto
Principe #2 du Reactive Manifesto : la résilience
Cela signifie que les systèmes réactifs intègrent une « tolérance » à la panne.
Qu’est ce que ça veut dire? Tout simplement qu’ils ont vocation à rester disponibles même en cas de panne. C’est là une partie intégrante de la notion de robustesse qui se cache derrière le Reactive Manifesto.
Pour cela, le Reactive Manifesto encourage le fait de répliquer des données et des fonctionnalités. Ainsi en cas de panne sur un composant par exemple, la fonctionnalité continue de tourner ailleurs dans l’infrastructure.
De même, les systèmes réactifs, intègrent une gestion des erreurs au niveau de chaque composant (logiciel). Ainsi la panne est limitée et identifiable. De même, les principes de délégation de responsabilité, permettent en cas de pépin, d’exécuter une tâche dans un autre contexte.
Principe #3 : l’Elasticité (ou souplesse du reactive manifesto)
L’idée ici, est que le système réactif reste disponible et opérationnel même en cas de forte variation de l’activité. En d’autres termes, les systèmes réactifs doivent répondre aux requêtes des utilisateurs et des systèmes en tout circonstance.
Ils doivent donc s’adapter aux changements d’activité de façon aussi automatisée que possible. La notion va donc plus loin que le terme de « scalabilité ». La scalabilité en effet, se réfère en général plutôt aux montées en charge. Ici on parle d’adaptation à la hausse ou à la baisse, en automatique et gérée directement dans le code.
Le Manifeste oriente donc vers des Architectures Réactives. Ces dernières évitent les risques de contention et privilégient une distribution des données et des ressources entre les composants.
Cette notion d’Elasticité permet d’envisager des réductions des coûts d’infrastructure, puisque l’application optimise elle-même ses traitements.
Principe #4 : Orientés messages
C’est le dernier des piliers, mais pas le moindre! Le Reactive Manifesto met en avant l’utilisation de messages asynchrones entre les différentes briques logicielles. On isole ainsi le fonctionnement de chaque composant. On assure un couplage « lâche » entre les éléments qui constituent le système réactif. C’est fondamental!
L’utilisation d’événements asynchrones peut sembler étonnant dans un contexte Temps réel, mais c’est justement lui qui contribue fortement aux notions d’elasticité et de tolérance à la panne car l’architecture est fortement modulaire.
Les messages pourront être rejoués et traités même dans un ordre non chronologique.
Attention toutefois! Appliquer ces principes nécessite de revoir ces principes de conception.
(Merci à Wilmer et à l’équipe Mind7 Consulting pour les inputs sur cet article!)
Les sujets qui m’intéressent le plus sont Data, Organisation et Temps Réel !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Andrea