Micro-services, ou les Barbies en nearly real time

Vendredi soir, il y avait quatre petites filles dans mon salon. Alors que la plus jeune, du bas de ses 9 mois, s’extasiait devant les bolides chantonnant de mon fils, les trois autres cherchaient de quoi s’amuser. Le médium artistique avait leur faveur et, déjà, elles lorgnaient avec envie sur les nouveaux marqueurs souffleurs juste offerts à Mathilda : placez la cartouche dans le marqueur, soufflez à l’extrémité opposée de la mine et vous envoyez un nuage d’encre sur le papier. Sur le parquet, les vêtements et les mains. Mais c’est un détail.

Or donc, comme je n’avais pas envie d’astiquer mon salon un soir de fête, j’ai subtilisé la boîte de marqueurs souffleurs et rassemblé les trois petites copines autour de moi. Telle une Mary Poppins de Noël, une Nanny Mc Phee improvisée, j’ai pioché sous le sapin un paquet plat et souple : “Regardez les filles, ça, c’est pour vous trois”. Et alors qu’elles déballaient leur cadeau, je leur ai expliqué: “Ce sont des dessins magiques. Il y a dix images que vous allez pouvoir colorier. Quand vous aurez fini, les grands les prendront en photo avec leur téléphone et les images s’animeront comme par magie sur l’écran [exclamation de joie]. C’est l’histoire d’un chien rose, j’espère que ça ne vous embête pas et que vous aimez le rose?” Les trois gamines me regardent, interdites, dans leurs robes de princesse fuchsia et leurs t-shirts danseuses rose bonbon. “Ouiiii, hurlent-elles en sautant dans le salon, on adore le rose!”.

Alors, on sort les crayons, les feutres à paillettes et les pastel-gel pour colorier les images de l’histoire. Arthus débarque, intéressé par ce matériel qu’il ne peut normalement pas toucher. Il s’empare d’un pastel et en met sur le parquet, ses vêtements et ses mains. Mais c’est un détail.

Déjà, je me réjouis de voir les images s’animer : lundi, je pourrai écrire un article sur les coloriages 2.0. et les subtilités technologiques des nouveaux jouets. Je scanne le QR code pour accéder à l’application, entre mon adresse mail pour recevoir le code d’activation et là…

“Merci. Le temps moyen d’activation est de 12h”

WHAT? ARE YOU F*CKING KIDDING ME?

Du coup, les filles ont lâché leurs crayons et se sont rabattues sur les Barbies. Une valeur sûre. Et surtout, immédiate.

L’immédiateté ou le temps réel en informatique qualifie une application ou un système “pour lequel le respect des contraintes temporelles dans l’exécution des traitements est aussi important que le résultat de ces traitements” (dixit Wikipédia). Le temps réel n’est pas utile à certains systèmes : les boîtes mail, les recherches Google, les payements via application. Pour ceux-ci, le nearly real-time est suffisant, autrement dit une latence de quelques secondes ou quelques minutes. Par contre, le real time est capital pour d’autres systèmes : certains chats en ligne, les vidéo-conférences, les systèmes d’auto navigation ou de freinage automatique, les opérations chirurgicales par robot interposé,… Le real time est nécessaire pour toutes ces applications fondées sur le principe d’immédiateté : j’envoie un message et je veux que la réponse soit instantanée, sinon elle perd de sa pertinence.

Vous vous souvenez de cet article sur la différence entre le stream et le batch? Pour résumer, soit les données arrivent et sont traitées dans le système au fil de l’eau, soit on attend d’avoir un petit tas de données pour les faire digérer par le système. Avec le temps réel, on est dans le stream, mais le niveau 5 étoiles. Pour reprendre ma métaphore d’école maternelle, c’est comme si, au moment où vous pensez “Tiens, Roudoudou a 2,5 ans, il peut entrer en maternelle”, Roudoudou est assis sur les petites chaises de la classe des poussins et vous avez une flûte de champagne en main pour fêter la fin de la domiciliation à la crèche et le retour de la caution.

Est-ce que c’est de la data science? Non, pas vraiment. Si on représente le traitement d’une donnée comme une chaîne d’actions, la data science se trouve à la fin de la chaîne : le temps réel est une façon de qualifier la chaîne elle-même. Appliquer des principes de data science sur des données en temps réel, cela pose surtout des questions d’infrastructure : il faut que le cheminement des données ET leur traitement soient optimisés pour permettre l’instantanéité de la réponse. Et ça, c’est le sujet préféré d’EURA NOVA ces dernières années.

En 2017, nous avons travaillé avec une société liégeoise mondialement connue pour ses ralentis vidéo. Certains systèmes de cette société sont en “real time”, notamment pour l’ingestion des images et les commandes sur ces images.

Imaginez plutôt. Lors d’un match de football entre le PSG et le Barça, dix caméras filment le terrain parisien pour ne perdre aucune phase de jeu ou morceau de gazon arraché par un coup de cales. Les images du match (minimum 60 par seconde) parviennent en temps réel au téléspectateur (et tant mieux : les supporters détestent voir des matches en rediffusé). Mieux, le montage des points de vue se fait en temps réel en fonction du jeu des équipes et du tracé du ballon : les points de vue des 10 caméras s’enchaînent de manière fluide et sans heurt.

Pour cette entreprise, EURA NOVA a encadré le développement d’un logiciel de gestion de donnée sur les flux vidéos, basé sur l’architecture microservice (c’est quoi, un microservice? au lieu d’avoir une boîte qui fait plein de choses différentes, on a des boîtes spécialisées qui font parfaitement une seule chose, indépendamment des autres boîtes). En bref, nous permettons de labelliser les images qui parviennent en flux continu et d’utiliser ces labels directement pour créer de nouveaux contenus. Par exemple, si Messi marque un penalty à la 57e minute, on peut directement labelliser les images “penalty”, “Messi”, “goal” et dans la seconde qui suit, créer un ralenti en récupérant ces labels. La subtilité, ici, c’est qu’on ne traite pas des données (la matière vidéo), mais les données sur les données (les métadonnées). Ici les contraintes temporelles sont plus lâches, on parle de nearly real time. Par contre, il est tout de même important que quand un label est créé, il ne faille pas attendre deux heures avant qu’il soit visible par un autre utilisateur ou micro-service.

Le microservice responsable de créer un label envoie un événement lorsqu’il effectue une action : “J’ai créé un label sur telle vidéo, à tel moment avec les tags penalty, Messi, goal”. Il est important de garantir le transport de cet événement pour que les autres micro-services soient au courant de la création du label (typiquement le micro-service responsable du ralenti), et cela dans une délai raisonnable : quelques dizaines de millisecondes. Une petite métaphore?

Traiter une donnée : Mathilda habille une poupée Barbie des pieds à la tête. Chaussures, robe, pinces à cheveux. Elsa et Alix aussi. Conséquence : habiller toutes les Barbies prend du temps, elles arriveront en retard au bal organisé par Ken.

Traiter un événement : Mathilda enfile les chaussures de Barbie n°1. Dès que c’est fini, elle crie à Elsa “Chaussures enfilées” et peut passer à une autre poupée. Elsa s’empare alors d’une robe et prend Barbie n°1 pour la lui enfiler. Quand Barbie n°1 est habillée, elle crie “Robe enfilée” à Alix. Alix prend les pinces à cheveux et les accroche aux cheveux filasses de Barbie n°1. Chaque petite fille a sa spécialité. Ici il est primordial que les messages “Chaussures enfilées”/ “Robe enfilée” prennent moins de temps qu’il ne faut à Barbie pour passer d’un poste à l’autre. Conséquence : la mise en beauté des Barbies ne prend que quelques minutes, et Ken est à la bourre pour préparer son bal. Quel idiot!

En résumé :

1. Posez-vous la question du real time : quelle est la latence limite acceptable par mon utilisateur?
2. Où cette limite devient-elle critique pour mon application?
3. Quelle solution architecturale dois-je mettre en place pour réduire la latence?