(si vous voulez lire les autres articles liés à SpringOne sur le blog d’Ippon Technologies, suivez le tag #springone)
Cette quatrième journée a pour moi été l’occasion de voir pas mal de nouveautés, et d’interviewer Eric Bottard sur Spring XD. Parmi ces nouveautés :
Une présentation de Tomcat 8 : j’en retiens en particulier un nouveau système permettant de faire des déploiements en parallèle de plusieurs version d’une même application. Il reste encore assez rudimentaire (on se base simplement sur un ordre dans le nom du WAR, par exemple monAppli#123.war), mais c’est déjà une belle avancée.
De manière plus amusante, le support des Websockets amène de nouveaux exemples, et je vous conseille pour cela de regarder le petit jeu fourni en local sur http://127.0.0.1:8080/examples/websocket/snake.html
Une introduction à Thymeleaf, qui est le système de template ayant le vent en poupe en ce moment (le nouveau site http://spring.io est développé avec Thymeleaf).
Une série de “best practices” pour le déploiement d’applications Spring sur AWS. Dans la pratique, il s’agissait plus d’une conférence sur AWS, car les applications Spring n’ont pas besoin de configuration particulière pour bien fonctionner sur le Cloud d’Amazon. L’astuce principale que j’ai découvert était d’utiliser les variables d’environnement fournies par AWS (par exemple RDS_HOSTNAME pour le nom d’hôte de la base de données), qui sont automatiquement comprises par Spring EL, afin de configurer simplement la datasource de son application. Simple et efficace !
Interview d’Eric Bottard
Bonjour Eric, est-ce que tu peux te présenter brièvement ?
Avec plaisir. Je travaille chez Pivotal (anciennement SpringSource/VMware) sur le projet Spring XD depuis quelques mois maintenant. Avant cela, j’étais Developer Advocate sur la plateforme Cloud Foundry.
Qu’est-ce que Spring XD, quels sont les cas d’utilisation dans lesquels il est pertinent ?
Il y a plusieurs façons de présenter ce projet, l’une d’elle est de le concevoir comme un outil distribué d’ingestion, d’analyse et d’export de données (typiquement vers l’ecosystème Hadoop, mais Spring XD s’applique à d’autres cas d’utilisation). Une importante composante du projet est également l’intégration de la notion de job batch. Le projet est né du double constat suivant:
- premièrement, l’écosystème Hadoop est aujourd’hui très fragmenté. Il y a un outil pour ingérer depuis une base de données relationnelle, un outil pour organiser des workflows, encore un autre outil pour collecter des logs, etc. Tous ont leur propre API, leur propre façon d’être paramétré, leur propre modèle d’exécution.
- deuxièmement, les problématiques de flux de (big) data sont des problèmes d’intégration. Et Spring dispose depuis longtemps de briques dédiées sur ces thématiques: Spring Intgegration, Spring Batch et Spring for Apache Hadoop
Spring XD est donc un runtime (et non un ensemble de jars comme on en a l’habitude avec le socle Spring) s’appuyant sur ces 3 projets et permettant de définir des flux de données de façon très simple, au moyen d’un Domain Specific Language. A titre d’exemple, si je veux collecter des données MQTT emises par une sonde, les filter et les archiver dans hdfs, cela peut être aussi simple que :
stream create mon_flux --definition “mqtt | filter --expression=payload>25 | hdfs”
Je peux ensuite très simplement créer une branche parallèle sur ce flux, ayant pour racine par exemple l’étape après le filtrage, pour effectuer une analyse simple et suivre le min, max, moyenne de cette température :
stream create analytics --definition “:tap:mon_flux | aggregatecounter”
Un parallèle que j’aime présenter est de dire que Spring XD est à Spring Integration et Spring Batch ce qu’Elastic Search est à Lucene : un Runtime s’appuyant sur ces technologies et permettant de manipuler facilement leurs concepts, au moyen de commandes shell ou directement de notre API REST.
J’ai vu que vous aviez une interface graphique assez sympa, avec quelles technologies l’avez-vous construite ? Est-ce qu’elle est également Open Source ? L’interface Web de Spring Batch était assez basique, est-ce qu’elle va la remplacer ?
Ce n’est qu’un début, nous avons à peine effleuré cette partie. Le développement de cette interface s’appuie sur Backbone.js et elle est bien entendu opensource, comme tout le reste du projet.
En ce qui concerne Spring Batch, rien n’est encore décidé, mais l’idée nous a traversé l’esprit en effet. Il s’agit avant tout d’écouter le feedback de la communauté.
Personnellement je fais du Hadoop en utilisant les APIs “normales”, qu’est-ce que je peux espérer gagner en utilisant Spring XD ?
Tout dépend de ce que tu fais aujourd’hui dans tes développements Hadoop. Si le gros de ton boulot consiste à prendre des données quelque part, les filtrer et les agréger avec d’autres pour in fine les sauver dans hdfs, alors il y a des chances que Spring XD puisse considérablement te faciliter la vie.
Si en revanche on parle de développements de jobs Map Reduce en soi, Spring XD n’est pas forcément adapté. En revanche, tu as tout intérêt à jeter un oeil sur Spring for Apache Hadoop (sur lequel s’appuie Spring XD) qui permet de faciliter le développement d’applications “Hadoop” (et maintenant YARN), en s’affranchissant de tout le côté répétitif de la programmation Hadoop (classe de driver main(), gestion du classpath, etc.). Le projet permet également d’assembler des applications suivant le modèle Spring d’injection de dépendances, de faciliter l’écriture de scripts manipulant hdfs (en groovy ou tout autre langage), de s’intégrer avec Spring Integration et Spring Batch et bien d’autres choses encore.
Pour résumer, Spring XD t’aide à amener tes données dans l’univers Hadoop (au moyen d’un DSL simple), puis Spring for Apache Hadoop t’aide pour tout ce qui est en aval, sur la partie programmation à proprement parler.
Quelle distribution Hadoop nous conseilles-tu avec Spring XD ? Cloudera, Hortonworks, ou votre propre Pivotal HD ? Ou simplement du Hadoop “Apache” ?
Dans la tradition de tout projet Spring, Spring XD est et restera compatible avec toutes les distributions que tu viens de citer. C’est là aussi un des attraits du projet : nous avons fait le nécessaire pour s’assurer que tout fonctionne correctement, en s’abstrayant des différences entre ces différentes distros. Il suffit de passer l’environnement sur lequel tu travailles en ligne de commande, par exemple –hadoopDistro=hadoop20.
De manière générale, toutes ces distributions se valent en termes d’intéraction avec hdfs et des APIs de base. Le versionning Hadoop et la gestion correcte des bonnes librairies est tout simplement un enfer pour le commun des mortels, nous avons fait le boulot une bonne fois pour toutes. Evidemment, si tu veux exploiter une fonctionnalité spécifique à une distribution particulière, il te faudra préciser la bonne distribution. A titre d’exemple, Pivotal HD est la seule distribution qui offre de véritables capacités SQL s’appuyant sur hdfs, au travers du moteur HAWQ.
Je suppose que peu de gens ont déjà entendu parler de YARN : peux-tu nous présenter YARN et Spring Yarn ?
YARN est une nouveauté de Hadoop 2.0, issue du refactoring du modèle d’exécution des jobs Map/Reduce présent dans la version 1. En deux mots, YARN est mécanisme permettant de faire tourner des applications distribuées sur Hadoop. YARN s’occupe du provisionning et du monitoring des processus. Dans ce modèle, un job Map/Reduce v2 n’est qu’un cas particulier d’une application YARN, alors que Map/Reduce et Hadoop v1 étaient intimement couplés.
Cela ouvre donc la porte à l’exécution de n’importe quel workflow de manière distribuée, mais ces APIs sont assez bas niveau. Il suffit de jeter un oeil à la documentation Apache de YARN pour se rendre compte à quel point ces têches sont répétitives. Spring YARN apporte le modèle de programmation Spring auquel tu es habitué à l’écosystème Hadoop/YARN.
Est-ce que Cloud Foundry proposera également d’héberger des services “Spring XD”, comme on peut déjà y déployer des applications Spring Boot ou Grails ? C’est la seule pièce de “Spring iO execution” qui semble ne pas être supportée.
Absolument, nous allons faire en sorte de faciliter le déploiement de Spring XD sur Cloud Foundry, et Cloud Foundry sera un environnement d’exécution de Spring XD, au même titre que YARN par exemple. Il y a en fait plusieurs façons d’appréhender le problème (est-ce que l’on déploie un “noeud” XD en tant qu’application Cloud Foundry, ou bien descend-on à la granularité du “module”?, etc.) Nous aurons certainement une première itération de cette intéraction dans la prochaine milestone de Spring XD.
