DevoxxFR 2017 – Jour 2

Trois semaines plus tard, je reviens sur mon jour 2 passé à DevoxxFR 2017. Au menu des Keynotes plutôt sympas, un zoom sur Infinispan et les bases in-memory et un petit update sur HTTP2.

De la responsabilité des ingénieurs, Keynote d'Éric Sadin

Dans cette Keynote, Éric Sadin nous parle de la place de l'ingénieur dans la société à l'âge du numérique. Selon lui, le début d’Internet peut être qualifié d’”âge de l’accès” (à l’information). Si on est toujours dans cet “âge de l’accès”, on rentre aussi dans “l’âge de la mesure de la vie”, qui se rapproche du mouvement “quantify self”. C’est-à-dire qu’on effectue de plus en plus de mesures (capteurs partout via l’Internet of Things), ce qui donne de plus en plus de données. Ces données sont à leur tour de plus en plus traitées, interprétées par des systèmes d’Intelligence Artificielle (IA) qui sont de plus en plus sophistiqués. Ces systèmes servent les besoins des grandes entreprises. Au final, "on marchandise la vie”.

Pour Éric Sadin, les ingénieurs (développeurs) sont au centre de tout ça, sans se rendre compte de leur impact. Alors qu’au XVIIIème siècle, l’ingénieur maîtrisait l’ensemble des processus. Ensuite, l’apparition des brevets entraîne l’achat des savoirs et des innovations par les entreprises. L’ingénieur est lui aussi “racheté” par l’entreprise. Conséquence : une parcellisation des tâches qui amène une moindre visibilité sur les finalités des recherches et une dissolution des responsabilités. L’autre impact est que l’ingénieur est désormais assujetti aux besoins industriels et économiques, donc aux tendances du marché décrites par les cabinets de marketing. Pour lui, l’ingénieur d’aujourd’hui est irresponsable car il ne réfléchit pas aux conséquences de ses travaux.

Ensuite, il enchaîne sur la question de l'enseignement. Sans le nommer, il parle du financement des grandes écoles par les entreprises et du problème que cela pose : Comment les écoles, sponsorisées par les grandes entreprises, peuvent-elles enseigner l'esprit critique vis-à-vis de ces dernières ? Petit tacle au passage à Xavier Niel qui se vante de ne pas avoir de bibliothèque, alors que pour Eric Sadin, la bibliothèque est le symbole d’une prise de recul et d’un esprit critique.

Au final, Éric Sadin pousse pour prendre du recul et faire des projets "obliques", c’est-à-dire qui ne sont pas dictés uniquement par les intérêts économiques des entreprises.

Ce que j’en retiens

• Nous, ingénieurs, développeurs, devons prendre conscience de l’importance de nos travaux et de leurs impacts
• Prendre le temps de prendre du recul

Video games: The quest for smart dumbness, Keynote de Laurent Victorino

Très bonne Keynote, intéressante et amusante (même si je n’en tire pas grand chose applicable dans mon quotidien), avec quelques trolls (faciles mais drôles) sur Java.

Laurent Victorino nous explique pourquoi l’Intelligence Artificielle des jeux vidéos semble souvent assez stupide, alors que l’IA a fait des progrès énormes dans tous les autres domaines. La réponse rapide, c’est qu’une IA trop forte dans les jeux vidéos, ça gagne à tous les coups et ça frustre très rapidement les joueurs qui ne peuvent plus gagner. Et un joueur frustré, ça n’achète pas les jeux. Donc, ici, c’est le parfait exemple de l’expression “c'est pas un bug, c'est une feature". Ce que je ne savais pas, c’est qu’on ne fabrique pas une IA idiote si facilement. Pour arriver à une IA assez stupide pour se faire battre par un humain, les développeurs fabrique la meilleure qu’ils peuvent, bien souvent très très forte, puis ils passent un certain temps à introduire des “bugs”.

Ce que j’en retiens

• Les développeurs d’IA de jeux vidéos ne sont pas incompétents, ils cassent juste leur travail pour s’adapter au niveau des joueurs
• Tester Gladiabots, un jeu où on configure une IA qui va combattre celle des autres joueurs

Architecture par la pratique : patterns d’utilisation de systèmes in-memory - WD-40 entre vos données et vos applis - Emmanuel Bernard / Galder Zamarreno

Une session plus technique pour continuer qui parle des systèmes in-memory en général et d’Infinispan en particulier (les speakers sont de Red Hat qui fournit la version payante d’Infinispan). Un concept à retenir, c’est que nous ne sommes plus dans des systèmes où la donnée est statique dans une base de données, mais où la donnée bouge, se copie, se transforme, évolue. On parle de rivières de données, de flux.

Petit zoom sur Infinispan. C’est une grille de données in-memory, de forme key-value, distribuée, élastique, avec un schéma optionnel. Je passe le détail de ce que tous ces mots veulent dire, je considère que vous les connaissez déjà.

La présentation fait ensuite le tour de quelques cas d’utilisation. Le premier, et le plus évident, est le cache (à l’instar d’un redis par exemple). Dans ce cas, le in-memory fait tout son sens, puisqu’on ne va pas perdre de temps à sauver la donnée sur disque. Comme la plupart des caches, on peut l’utiliser embedded dans une application (meilleures performances), soit dans un cluster (pour avoir un cache partagé entre serveurs). Le cas suivant est d’utiliser votre système in-memory comme primary store, on peut configurer Infinispan pour qu’il sauvegarde ses données sur disque, donc pas que in-memory. À noter qu’Infinispan supporte les transactions XA et qu’on peut utiliser des ORMs comme JPA ou Spring data (Emmanuel Bernard était développeur sur Hibernate). Cas intéressant d’utilisation est celui du “Data Virtualization Duck Taping” où on va utiliser notre système in-memory comme base de données virtuelle, accessible par notre super hype nouveau microservice, au-dessus de notre vieille base de données qui est toujours accédée par notre ancien système qu’on aimerait bien décommissionner un jour. J’avoue qu’à ce moment là j’avais plein de questions pratiques dans ma tête sur ce cas d’usage : comment la synchronisation à la base sous-jacente est-elle réalisée ? quel overhead ? Quelles limites d’avoir des schémas trop éloignés ? etc. mais la présentation ne s’y est pas arrêtée. On reste dans l’idée de migration vers des microservices avec le pattern “Change Data Capture” et l’outil Debezium, développé aussi par Red Hat. Cet outil va écouter tous les changements de votre base de données existante pour les transformer en événements. Ces événements sont injectés dans un Kafka afin que d’autres applications puissent les consommer.

Ce que j’en retiens

• La tendance c’est d’aller vers des architectures de flux, des “rivières de données”
• Autre tendance qui persiste depuis quelques années : migration vers des architectures microservices.
• Les patterns “Data Virtualization Duck Taping” et “Change Data Capture” peuvent être d’autres solutions lorsqu’on veut migrer un système existant vers une architecture microservices.

HTTP2 du point de vue développeur, Sébastien Augereau

Quickie (session de 15 minutes) sur l’évolution du protocole HTTP. Les principaux points : on passe à un protocole binaire, plus compact, ce qui a pour effet d’être plus rapide, mais moins lisible pour le développeur. On utilise du multiplexing, une connexion HTTP est utilisée pour télécharger plusieurs ressources. Au final, ça va plus vite. On parle de d’un réduction de 25 à 50 % du temps de chargement des pages. Facile à mettre en place, dans leur exemple en Java ça fait 5 lignes de code. Les CDNs comme CloudFront l’ont déjà mis en place, sans action requise de votre part.

Ce que j’en retiens

• HTTP2 ce n’est plus uniquement “pour plus tard” mais à intégrer dès aujourd’hui sur nos projets, ça coûte pas cher.