Compte-Rendu du petit-déjeuner “Le réactif”
Jeudi 21 Janvier, l’équipe en charge des technologies Réactives d’OCTO Technology a présenté sa vision des nouvelles architectures Réactives (Vidéo ici, slide là).
La conférence était découpée en trois parties :
- Que sont ces nouvelles architectures et pourquoi s’y intéresser ?
- Un retour d’expérience d’un grand projet réactif, avec des contraintes fortes de scalabilité et de disponibilité
- Des pistes pour gérer la transition vers ces nouvelles approches, au niveau organisation et gestion du changement
La pression sur les SI étant de plus en plus forte, les architectures précédentes peinent à répondre aux sollicitations. Des limites physiques infranchissables se rapprochent inexorablement, au niveau mémoire (les GC peinent à gérer de gros volumes), CPU (la fréquence n’augmente plus), disque (compensé en partie par les disques SSD) ou réseau (limité par la vitesse de la lumière).
Les approches réactives proposent d’organiser les architectures autour de la répartition des traitements. Le plus en amont possible, les flux sont distribués vers différentes chaînes de traitements les plus hermétiques possibles. Ainsi, le SI devient scalable et est en capacité de dépasser les limites physiques de chaque chaîne de traitement. De plus, les flux sont géré à l’aide d’événements consommés via une approche asynchrone.
Cela n’est pas sans difficulté : il faut accepter de perdre les notions de transactions, gérer les situations où des traitements s’exécutent sur les mêmes données dans des chaînes de traitements disjoints, et cela sans imposer de verrou (consistance à terme). L’idéal étant de ne jamais avoir de concentration entre les technologies pour organiser l’intégralité du SI.
OCTO insiste sur l’importance d’intégrer ces difficultés dès la phase de conception de l’architecture. Le métier est un élément important pour monter une architecture réactive, que cela soit dans les stratégies de distributions des traitements ou dans l’approche “Design by query” où les tables des bases de données sont organisées suivant les requêtes à appliquer. La dénormalisation des données est la règle.
OCTO propose une architecture CQRS où les flux de lectures s’effectuent via des services WEB et les flux d’écritures s’effectuent via des messages décrivant les mutations. Les messages sont traités par Spark Streaming. Ce modèle d’architecture permet de mémoriser les mutations dans un Datalake à fin d’analyse de l’historique du SI ou pour le Plan de Reprise d’Activité (PRA) en réinjectant l’intégralité des flux.
Dans la deuxième partie, OCTO a présenté la démarche mise en oeuvre sur un projet et montré les difficultés à atteindre les objectifs de scalabilité et de résilience. L'accumulation de technologies présentant ces caractéristiques ne fait pas pour autant une architecture capable de résister au crash de chaque maillon.
Lors d’un test, un flux en légère surpression a été injecté dans le SI. Pendant l’injection, on a provoqué un arrêt brutal d’un serveur puis sa remise en fonctionnement à partir d’une machine vierge. Après un délai raisonnable pour permettre au système de rattraper son retard, les données produites sont analysées pour s’assurer de l'innocuité du dysfonctionnement. Des ajustements des paramètres ont été nécessaires pour garantir la résilience de la solution. Dans ce cas précis, un minimum de 23 serveurs sont nécessaires.
Une automatisation totale de la plateforme est indispensable pour gérer ces architectures. Une approche DevOps est nécessaire. Sur le projet cité en exemple c’est Ansible qui a été choisi pour automatiser le provisionning des environnements, du poste du développeur dans des conteneurs LXC, aux plateformes d’intégration dans le Cloud à la production sur des machines physiques.
Enfin, la dernière partie présentait les difficultés d’organisation et de montée en compétence des équipes. Ces technologies et ces approches étant très éloignées des us et coutumes des SI classique, l’évolution des équipes n’est pas sans douleur.