Softshake 2015

Après deux jours passés à Softshake et 10 sessions, nous avons un bon état des lieux des tendances du moment. Vous pourrez trouver ici le programme complet de la conférence pour avoir un aperçu des autres sujets. Voilà en quelques mots ce que nous avons retenu :

Big Data : Deep learning mais pas seulement

Le deep learning permet de supprimer les problématiques de construction des 'features' en entrée des réseaux de neurones. En effet, il permet de laisser le réseau construire ses propres features/abstractions à travers de multiples couches (plusieurs dizaines), sans pour autant taper l'écueil du nombre de poids à optimiser dans un MLP classique. La speaker présentait le deep learning comme la raison du retour en force des réseaux de neurones, qui avait été dépassés auparavant à cause de cet écueil. Les slides étaient très clairs, et les exemples assez bons. Par contre, au-delà de la reconnaissance d'images, nous aurions bien aimé qu'on nous parle également d'autres domaines, sur la reconnaissance de la parole par exemple, ou sur un cas plus général.

Apache Drill est aujourd'hui l'un des moteurs qui améliore encore l'accès SQL au-dessus des outils de l'écosystème Hadoop. Le mécanisme de plan d'exécution est là, la capacité à tirer parti des capacités des stockages sous-jacents aussi. Ainsi, il est possible de requêter des fichiers semi-structurés comme JSON, des fichiers Apache Parquet, mais aussi des bases de données relationnelles. Pas d'update par contre, on reste dans le monde du décisionnel.

Apache Zepellin est un projet de la fondation Apache qui mérite vraiment le détour. C'est un serveur qui permet de proposer des Notebooks avec des morceaux de code dans différents langages, pour les exécuter sur le serveur. C'est idéal pour les démonstrations, voire pour les consoles des administrateurs. Un éditeur local permet d'écrire du code, d'extraire des paramètres dans un formulaire. Le résultat de l'exécution peut être un texte, un tableau (présenté en colonne, graphe, etc.).

Cassandra et Spark : l'intégration est fine, avec l'exploitation des capacités de Cassandra dans le calcul du plan d'exécution de Spark SQL. Cassandra travaille à pouvoir produire un flux de mutation d'une base, pour pouvoir le brancher sur un Spark Streaming et réagir à chaque modification, comme un trigger. Il est également possible d'exploiter les règles de distribution de Cassandra pour colocaliser les jobs Sparks avec les instances Cassandra et éviter ainsi les communications réseaux.

Programmation fonctionnelle : des exemples concrets

Sur les aspects fonctionnels, la communauté des développeurs fait aujourd'hui beaucoup d'essais. Parmi les avantages marquants le fait que le code soit beaucoup plus centré sur la donnée. Ainsi, JSON - la notation Data Literal de JavaScript - est l'un des facteurs de succès de ce langage. Côté Microsoft le côté fonctionnel et réactif a été conceptualisé sous le nom d'architecture IODA. Pour faire simple, là où l'injection de dépendance rajoute une interface pour supprimer les dépendances, l'architecture IODA ajoute une interface sous la forme de Stream et d'observable. Le lien entre le stream et le composant du domaine est extrait dans un code très déclaratif et fonctionnel. Le code objet a encore du sens mais encapsulé dans le domaine. Enfin, les Furets ont montré comment ils sont passés progressivement d'un modèle métier classique à une cohabitation entre un modèle métier et un modèle clé/valeur côté interface Web et côté back-office. Ce passage en un modèle clé/valeur leur a ainsi beaucoup simplifié la mise en place de Streams et de micro-batches comme Spark.

Conteneurs : de l'industrialisation de Docker aux unikernels

Google avec Kubernetes a fourni une implémentation open source proche de son outil interne Borg. Conçu pour être utilisable partout (sur un PC en local, sur le cloud) mais très bien intégré avec Google Cloud Platform, Google se lance dans la guerre de ce que nous pouvons appeler les OS de cluster. Avec les principaux concurrents comme Mesos ils ont lancé une initiative cncf.io (Cloud Native Computing Foundation) pour standardiser un certain nombre de points. A suivre. Toujours dans le domaine des conteneurs, Docker a acquis depuis quelques mois une très forte notoriété. Mais Docker reste basé sur des conteneurs qui nécessitent un OS pour s'exécuter. Or, dans un conteneur la bonne pratique est de faire tourner un seul process. Les Unikernels vont plus loin en supprimant la notion d'OS et de framework. OSv par exemple va permettre de construire des VM qui vont booter sur un ".so", par exemple "java.so" qui va être à la fois l'OS et les processus de la machine virtuelle. Plus de séparation d'espace mémoire, cela conduit à de jolis gains en terme de performance réseau : jusqu'à x18 dans certains cas. Là encore, à suivre : les gains sont impressionnants mais les 40 ans d'outils sur les OS - par exemple pour paramétrer, monitorer, diagnostiquer - sont à reconstruire différemment.

Cloud : place au BaaS

Dans la session Un back-end, on peut s'en BaaS-ser, on revenait sur les critères de choix d'un back-end, notamment dans le cas d'une app mobile, et la pertinence de choisir un BaaS. C'est un REX sur l'utilisation de Parse pour les applications Stop-tabac de l'Université de Genève. La rapidité de mise en oeuvre est clairement un critère déterminant, même par rapport à un PaaS. Par contre le débogage et l'industrialisation sont rapidement des écueils. Ma compréhension est donc qu'on peut aller beaucoup plus loin que du PoC avec ces plateformes, et que la scalabilité ne sera (presque) jamais un problème, par contre il faut rester dans une complexité fonctionnelle réduite (proche du CRUD). En effet la partie code côté BaaS n'est pas encore "sèche", même si ça bouge pas mal sur ce sujet en ce moment (voir les annonces de Parse sur Heroku et node.js notamment).

Front Web : CSS3 et stratégies de test

CSS3 a une fonctionnalité vraiment sympa (Flexbox et autres), permettant de gérer les mises en pages en bloc, très simplement, sans injecter des divs et des divs. La réorganisation des blocs à l'horizontale, la verticale, voire l'ordre des blocs, est facilité. Tous les navigateurs ne gèrent pas encore tous les besoins, mais il existe des contournements permettant de s'adapter aux navigateurs cibles.

Il y avait également des démonstrations très intéressantes sur comment bien utiliser Karma et Protactor pour des tests en JavaScript qu'il est difficile de synthétiser en quelques mots. Au niveau des tests toujours, le  "mutation testing" est un concept intéressant qui consiste à modifier le comportement d'un logiciel - par exemple remplacer i++ par i-- - et à vérifier que les tests unitaires qui couvrent cette ligne vont bien tomber en erreur. Nous l'avions d'ailleurs abordé sur notre blog il y a quelques années. Très bonne garantie pour aller au-delà de la couverture de code, il faut cependant ne pas en abuser car certains cas de mutation n'auront d'un point de vue métier aucun impact. Nous les réserverons donc pour du code très sensible.

Performance

Dans "Les secrets de la JVM pour les algos à haute fréquence", Philippe Prados nous a fait plonger dans les arcanes de la JVM et de l'utilisation plus optimale des ressources au niveau des processeurs. Toujours illustré par des exemples minés dans les sources des librairies de base et de la JVM, il illustre comment limiter les allers-retours entre registres, différents niveaux de cache et RAM. A plus "large" échelle, il présente des stratégies pour synchroniser (ou non) des updates de mémoire entre les coeurs. Le titre fait référence aux "algos à haute fréquence" mais il est bien réducteur. Cette approche peut s'appliquer au calcul scientifique en général et fournit des arguments rares et construits pour notre prochaine discussion du type "la JVM c'est nul, ça n'avance pas."

Agilité

Un REX a été donné sur la mise en place d'un centre nearshore Agile en Ukraine pour tous les développements de Swissquote. Le REX était intéressant en soi : Swissquote voulait accélérer, ils sont alors passés de 100 personnes en Suisse faisant développement et maintenance à 100 personnes en Suisse pour la maintenance et 100 personnes en Ukraine pour les projets - centre nearshore géré par un provider. Leur session racontait leurs enseignements sur cette "route". Sans être novateurs, une fois publiés leurs slides resteront intéressants à étudier.

Et pour finir

Time and Computer est une conférence très intéressante sur le problème du décalage entre l'heure astronomique et l'heure universelle. La gestion des secondes additionnelles n'est pas évidente. A tel point que le Nasdaq est fermé pendant cela, afin d'éviter des bugs sur les algos de trading haute-fréquence. Nous avons appris qu'il faut de plus en plus, ajouter des secondes supplémentaires. Dans quelques années, il en faudra une par mois ! Du coup, un algo naïf qui prend deux dates EPOCH pour connaitre le nombre de jours (/ 86400), va tomber sur un nombre de jour variable. Même les GPS auront un problème. En effet, un byte permet d'indiquer l'ajustement à appliquer. 8 bits sera trop peu dans quelques années.