La Résilience améliore l’expérience utilisateur (2/2)
Dans l’article précédent, nous avons pu comprendre en quoi la résilience et l’implémentation de patterns pouvait améliorer l’expérience utilisateur.
Nous allons maintenant nous attaquer au déploiement, et à la manière de mettre à disposition de nouvelles fonctionnalités à des utilisateurs sans les impacter. Grâce à ses mécanismes, nous diminuons les risques d’impact utilisateur et sécurisons nos livraisons applicatives.
5/ Le BlueGreen Deployment
Le principe du BlueGreen est simple : permettre de livrer une nouvelle version applicative sans interruption de service tout en la sécurisant, et ainsi pouvoir revenir en arrière rapidement en cas de problème (rollback).
Pour ce faire, la nouvelle version applicative sera livrée en production en parallèle de la première, mais non active (production cachée). Des tests peuvent ainsi être faits sur ce nouvel environnement sans impacter l’utilisateur.
C’est un des mécanismes intéressants qui permet de facilement passer d’une version applicative à l’autre en redirigeant le trafic de la version Blue à la version Green. Pour cela il faut penser compatibilité ascendante...
Par exemple, sur notre site de souscription de contrat d’assurance automobile, nous avons mis à jour les tarifs 2020 sur la nouvelle version (green), les tests validés, nous basculons les clients sur cette version pour leur mettre à disposition ces nouveaux tarifs. Après 2 heures d’utilisation, un problème est constaté (remontée client, logs applicatives d’erreur en hausse…) et nous rebasculons sur la version précédente (blue) sans relivraison, avec un minimum d’impact.
Attention : il faut avoir en tête que le BlueGreen peut être compliqué en cas de modification de base de données, de dépendance à d’autres système, etc… et qu’il faudra nettoyer le code applicatif assurant la compatibilité ascendante dans les prochaines versions.
6/ Le Canary Deployment
Le Canary Deployment est l’image du canari placé au fond des mines de charbon pour alerter les mineurs d’un coup de grisou… Ici, on utilise cette image pour mettre à disposition une nouvelle fonctionnalité/version à une partie des utilisateurs (proche de l’A/B Testing) pour valider son bon fonctionnement avant de déployer cette nouveauté à l’ensemble des utilisateurs.
En comparaison au BlueGreen qui impacte tous les utilisateurs, le Canary ne va impacter qu’une partie des utilisateurs. On redirigera quelques utilisateurs (un peu VIP, ou BetaTesteur…) sur la nouvelle version (green) en laissant les autres utilisateurs sur la version actuelle (blue). Après validation par les VIPs, on basculera l’ensemble des utilisateurs sur la nouvelle version (green), dans le cas contraire, nous rebasculerons les VIPs sur la version précédente (blue).
Dans notre exemple précédent, on pourrait imaginer proposer un parcours de souscription différent aux clients de plus de 50 ans, afin de confirmer sa bonne prise en main avant de l’ouvrir à l’ensemble des clients.
7/ Le Feature Flipping
Le Feature Flipping permet d’activer/désactiver une fonctionnalité de manière manuelle SANS relivraison d’une version applicative. Cette fonctionnalité est présente dans la version actuelle, mais n’est pas forcément activée par défaut.
Ce dispositif va permettre d’activer/désactiver une fonctionnalité spécifique à un instant T en fonction de différentes raisons (marketing, métier, anticipation problème ou d’évolution technique) pour tous les utilisateurs.
Exemple : la souscription est terminée, le contrat est disponible mais les imprimantes sont en panne, l’application ne va pas solliciter le service d’impression mais bascule sur une impression au format pdf, que je pourrai imprimer plus tard si je le souhaite.
8/ Le Throttling
Le Throttling qui signifie “Etranglement” est un mécanisme d’alerte automatique permettant d’éviter un goulot d’étranglement et bloque ou limite un service pour le (sur)consommateur en cas de nécessité (dépassement de la limite autorisée).
Ce mécanisme va, dans un premier temps, alerter l’équipe d’exploitation de la sollicitation anormale du service par un consommateur : seuil d’alerte. Ensuite, la mécanique pourrait aller jusqu’à bloquer l’accès à ce service pour ce consommateur en cas de dépassement du maximum autorisé : seuil critique.
Le site de souscription de contrat automobile utilise le service d’immatriculation des véhicules tout comme le site de déclaration de sinistre. Jour de “Black Friday”, le marketing lance une promotion de 15% sur les contrats d’assurance automobile. Le site de souscription est victime de son succès et sur-sollicite le service d’immatriculation, ce qui est un risque pour les clients ayant un sinistre à déclarer. Grâce aux seuils d’alerte par consommateur, l’équipe d’exploitation surveille les seuils, prête à bloquer l’opération promotionnelle afin d’assurer la disponibilité du site de déclaration de sinistre, afin de ne pas impacter ses clients sinistrés.
Il existe encore d’autres principes de résilience qui permettent d’améliorer l’expérience utilisateur, comme l’asynchronisme, l’event driven… une occasion supplémentaire pour moi d’écrire un troisième article sur le sujet, ou de donner envie à d’autres de se mettre à en écrire 😁
Un remerciement particulier @xdesmarest pour la relecture attentive et @jcarreaud pour les illustrations.
