Alors, des sujets vraiment variés, il y a une partie sur laquelle je ne vais pas pouvoir parler car c'est un projet fermé pour l'instant, peut-être que l'on en parlera en Septembre (NdR : l'interview a été enregistrée cet été). Je travaille beaucoup sur tout ce qui est Web-Oriented Architecture ; bien sûr on a créé Play Framework, qui devient de plus en plus mainstream, aujourd'hui on en entend parler ; le Guardian l'utilise, LinkedIn et Tumblr l'utilisent, beaucoup des grands du web l'utilisent, mais aussi cela rentre maintenant en entreprise, par exemple on en entend parler même aussi chez Gartner qui est plutôt orienté entreprises. On travaille beaucoup donc sur le web : je suis CTO de Zenexity, et Zenexity c'est le Web-Oriented Architecture, comment faire des applications web distribuées, scalables, voilà les sujets sur lesquels on travaille. Les data que l'on manipule sur le web, ce sont les thèmes sur lesquels nous sommes.
2. Tu parles de Realtime Web, qu'entends-tu par là ?
En fait, aujourd'hui quand un utilisateur, pas forcément avancé, ouvre un navigateur web, qu'il ouvre Twitter ou Facebook, il va avoir des mises à jour tout le temps, des notifications, des nouveaux tweets, en dix secondes par exemple, il va avoir dix autres tweets, etc. Alors, cela commence comme cela, mais tous les sites web vont aller dans ce sens-là, on a un monde qui bouge, tout le monde est sur Internet, tout passe par le web et toutes les applications vont en bénéficier. Par exemple, pourquoi ne pas ouvrir son compte bancaire et avoir les courbes des transactions acceptées, et ainsi de suite ? Tout est à imaginer, dans un monde pur realtime. Il y a des messages qui passent tout le temps, on reçoit les notifications lorsqu'elles arrivent. J'ai parlé d'un exemple de banque, mais cela peut aussi être dans le monde de la finance, de la presse, dans n'importe quel domaine. Les techniques d'architecture de ce type de systèmes sont complètement différentes. Il faut adopter un autre mode d'architecture pour répondre à ce type de besoins. Ceux qui ont de l'expérience dans le mode entreprise savent que tout est orienté batch, faire tourner certaines choses la nuit, le samedi le système est parfois arrêté pour redémarrer, pour faire certaines choses. Il faut oublier ça. Au niveau applicatif, il faut que cela soit beaucoup plus realtime, les échanges de données qui arrivent en temps réel, mais pas uniquement. Aujourd'hui lorsque l'on parle d'analytics, on parle de data warehouse, une machine à part, statique, on doit faire des extractions de données, essayer de l'analyser. Tout cela va aussi disparaître au profit d'analyses realtime, c'est-à-dire des fonctions, des équations qui tournent en temps réel sur les données de la prod. Ceci afin de donner des opportunités, aussi bien de pub, que business ; et ça tourne en temps réel. Encore une fois, ce n'est pas un fantasme, ça existe aujourd'hui ; quand on va sur LinkedIn et que l'on rajoute un, deux ou trois skills (NdR : compétences), toutes ces données sont analysées en temps réel, pour savoir ce qui a changé dans la vie de cet utilisateur, peut-être qu'il va quitter son travail, et c'est exactement là qu'on peut lui chercher un travail ; peut-être qu'il vient d'intégrer une nouvelle position et il cherche à recruter quelqu'un. Et ainsi de suite. Il y a beaucoup d'analytics temps réel qui commencent à émerger, et même en France beaucoup commencent à le faire, Viadeo par exemple en fait partie. Il faut vraiment maintenant moins séparer les données, et faire émerger un monde temps réel. Et il y a beaucoup de challenges, d'où la nécessité de complètement changer l'architecture pour répondre à ces nouveaux besoins d'échange de données temps réel.
En fait, ce qui est important dans Play Framework c'est la vision. Nous, Zenexity et moi-même, on aime bien utiliser les outils qui existent. On n'est pas là à inventer pour inventer. Le début de Play, c'est qu'on a pris les frameworks qui existent, Spring MVC et les autres, et on a essayé de faire avec ; à des moments, on a vu que des choses n'existaient pas, et on a essayé de faire des libs (NdR : bibliothèques) autour, pour que ça fonctionne bien. Et à un moment, on a fait un package, on l'a appelé Play Framework et on a évolué comme ça. Après, Play 2, c'était un changement radical, car il y avait ce problème d'architecture scalable mais aussi realtime, et il fallait faire un framework qui prend ces problèmes, de base, qu'il soit conçu pour régler ces problèmes-là, et c'est la raison pour laquelle nous avons fait Play 2. Nous nous sommes dit, il faut que cela soit dans son architecture le fait que ce soit realtime, scalable, que cela prend en considération les échanges et les transformations de data. C'est-à-dire que je vais recevoir des data qui viennent de plusieurs sources, du web, de fichiers, de bases de données, dans des formats complètement différents, JSON, HTML ou binaire, et ce que je veux faire c'est transformer ces données-là, pour faire des représentations en rapport avec le domaine de l'application que je veux faire. Un tweet par exemple, c'est des données brutes, je peux vouloir ne voir que la photo qui est attachée, ou que le temps qui est associé à tel utilisateur, je peux le voir comme je veux. Et ça c'est une petite représentation de tweets. Pour toutes ces données-là, on va faire une ou plusieurs représentations pour chaque donnée et on va travailler sur ça. Et pour faire ça, il faut une façon de faire, un paradigme, et on s'est dit, la programmation fonctionnelle c'est le bon paradigme pour ce type de transformation de données, car c'est super-simple à faire avec la programmation fonctionnelle. Pour Play 2, on s'est donc dit qu'il fallait qu'on intègre bien la programmation fonctionnelle directement dans l'architecture. Pour Play 2.1, on a fait évoluer la lib JSON pour qu'elle soit aussi puissante pour ce genre de transformation de données. Et là, dans les plans pour continuer à évoluer, on va faire la même chose. Aller vers le realtime web, vers la transformation de données. Par exemple, l'API Form va devenir aussi maniable et composable que l'API JSON. On a beaucoup d'idées, on va intégrer plus de drivers de datastores de façon complètement "reactive". En fait, on cherche à résoudre un problème, et on va continuer dans cette direction. On va aussi intégrer plus d'outils pour aider les développeurs, car une fois que l'on a résolu ces problématiques par nature complexes, si on propose un modèle de programmation plus simplifié pour ces problèmes, à un moment donné, il ne reste plus qu'à faire le fonctionnel, le domaine. On ne va plus passer tout son temps à parser du JSON, non, ça c'est des problèmes simples. On va pouvoir se focaliser sur la valeur de business. C'est vraiment ça la vision du framework.
Alors en fait, très bonne question. On dit toujours que Play 2 est un framework pour la JVM. Il supporte de base le langage de programmation Java et Scala, de la même façon. Côté Java, c'est du Java natif, on ne va pas essayer de faire des API étranges pour un développeur Java ; et même chose pour Scala, on ne va pas faire des API qui ressemblent à Java pour un développeur Scala. Mais ce qui est intéressant dans Play, c'est que l'on peut faire les deux dans un même projet. On travaille avec des clients - 90% de ce que l'on fait chez Zenexity c'est du Scala, du Play / Scala - mais on a des clients, et c'est une question très difficile, qui ont dans leur organisation beaucoup de développeurs Java et tu ne peux pas migrer en Scala du jour au lendemain. Mais ce qui est intéressant avec Play, c'est que tu peux partir en Java, laisser certains partir en Java car on n'a pas besoin des capacités de transformation de données super évoluées, et dans certaines parties où il y a des choses sophistiquées, de la transformation de données, de machine learning, des trucs comme ça, eh bien on peut faire un contrôleur Scala, et cela va cohabiter et c'est ça qui est intéressant. C'est pour ça, le choix entre Play Java et Play Scala, on peut choisir à n'importe quel moment. Les organisations qui font du Java pourront prendre Play Java. Elles vont gagner en scalabilité et sur d'autres propriétés intéressantes et, petit à petit, au fur et à mesure des fonctionnalités évoluées ou sophistiquées, alors ils peuvent intégrer du Scala et former progressivement leurs développeurs à faire du Scala. Et vraiment c'est quelque chose que l'on fait. On n'essaye pas d'imaginer la situation, c'est notre travail de tous les jours d'accompagner nos clients à passer vers un monde plus fonctionnel, faire du traitement de données, mais progressivement. Il ne faut pas dire "on va faire du Scala", et que tout le monde soit au chômage technique car ils ne connaissent pas le langage. Il faut être réaliste, et c'est ce que l'on cherche à être. Et c'est pour cela que nous avons conçu Play 2 de cette façon.
En fait, c'est super intéressant. Le modèle que l'on a - et on parle souvent avec les fondateurs de Typesafe - le modèle est un peu étrange de collaboration entre Zenexity et Typesafe. Les gens ne comprennent pas toujours. Ils nous disent "vous avez créé Play, mais maintenant Play c'est Typesafe, qu'est-ce que ça veut dire ?" Nous si on a créé Play Framework, on a voulu trouver une société qui va héberger Play, qui va prendre Play, et faire tout ce qui va autour, des services, du training, et ça dans tous les pays, partout. Il faut de la documentation, il y a beaucoup de choses pour maintenir un produit open source. Nous chez Zenexity, on n'a pas ces compétences pour le faire. Les gens qui travaillent chez Zenexity, ils veulent toujours de nouveaux projets, surtout des projets qui ressemblent à des projets de startups, avec beaucoup de challenges. Et on ne veut pas faire ce genre de tâches, c'est un autre modèle de business. Il y a beaucoup de choses intéressantes dans un framework web et les challenges que ça pose, mais c'est un modèle de business différent. Alors on avait un choix : est-ce que l'on devient cette société, ou est-ce que l'on reste tel quel, et on délègue le framework à quelqu'un pour qu'il évolue ? Et Typesafe était vraiment un bon candidat, car Typesafe a tout ce qui est scalabilité et parallélisation, transformation de données, dans leurs gènes. Et quand on leur a donné, on les a aidés à fonder la boîte Typesafe, et depuis le début, on voit que ce sont des valeurs qui comptent pour eux. Et c'est pour cela que l'on s'est dit, c'est exactement l'environnement, la stack, qu'il faut pour Play Framework. Alors maintenant, comment ça se passe ? Typesafe maintient et offre des services autour de Play. Nous Zenexity et surtout moi et Guillaume on est les leads du design et de l'architecture. Quand il y a des décisions d'architecture on en parle avec les équipes de Typesafe pour discuter les alternatives et décider quelle est la meilleure façon de faire évoluer le framework. Alors bien sûr, il y a aussi certaines parties que l'on implémente nous-mêmes, mais c'est toujours une collaboration. On a bien sûr des meetings toutes les semaines, pour parler de ce qui se passe, parler des idées, des évolutions qu'on va faire sur Play Framework. La collaboration avec Typesafe ne s'arrête pas à Play Framework, on essaie aussi de travailler pour eux sur d'autres applications, on est en relation de partenariat très forte avec Typesafe.
Ce qui est intéressant, dans ce monde du reactive, de web scalable, c'est que ça évolue très vite. Il y a des frameworks dont on entend parler, node, ensuite vert.x, et ainsi de suite. Mais ce qui est intéressant, en fait, c'est que ce mouvement est très bien, ça réveille, on a besoin de nouveaux outils au-delà de ceux que l'on utilisait, de nouveaux concepts, et c'est pour cela que je pense que c'est bien. Après, vert.x qu'est-ce qu'il va offrir ? Il va offrir une opportunité de scalabilité. Mais avec cette opportunité, il faut vraiment un modèle de programmation. Je ne peux pas travailler, par exemple, qu'avec des callbacks ; le code devient du spaghetti. Au bout d'un moment, on va faire des callbacks de callbacks de callbacks, on va avoir un milliard de niveaux de nesting, d'imbrication, et cela devient très difficile à travailler avec. C'est pour cela qu'il ne faut pas seulement l'opportunité, mais il faut aussi un modèle de programmation. Et on voit qu'aujourd'hui on commence à avoir ça. Par exemple, SpringSource a ouvert et annoncé son framework, qui va vers un modèle de programmation. Car il ne suffit pas d'avoir l'opportunité d'être reactive, mais il faut un modèle de programmation pour guider les développeurs, car face à tant de complexité, c'est difficile. Dans une organisation, il faut des patterns, des façons de faire, ainsi de suite. Et c'est l'API qui va permettre de faire ça. Et c'est pour cela que je pense qu'il faut plus que l'opportunité. Et c'est pour cela que c'est cela qu'on offre, mais d'autres aussi, on n'est pas seuls. Et vraiment on n'est pas là pour vendre Play Framework ou autre. Mais on est sûrs qu'il faut un modèle de programmation pour prendre en considération ce genre de problèmes. On n'est pas les seuls à le dire. Côté .Net, il y a Reactive Extensions qui font exactement ça, et depuis longtemps. Erik Meijer, ça fait longtemps qu'il en parle. Mais il n'est pas seul à en parler. Netflix, c'est un service qui fait de la vidéo. Ils sont pragmatiques dans tous leurs choix d'architecture, ils ont pris un modèle qui ressemblent beaucoup à Reactive Extensions parce qu'ils savent que c'est une problématique de programmation complexe, et si on ne prend pas le bon paradigme ou les bonnes API, on va souffrir. Et donc, ils ont pris le même modèle que Reactive Extensions, et ils l'ont rajouté dans leur infrastructure, en Java. Spring va faire la même chose, nous on a fait la même chose avec les Iteratees / Enumerators. Voilà, ce sont les mêmes idées, mais ce que je dis c'est de ne pas seulement se focaliser sur combien de requêtes par seconde, mais aussi faciliter le travail du développeur pour qu'il fasse la bonne chose. Parce que l'on dit, c'est une seule loop, une seule thread de tout le système, faut pas bloquer, ça personne va pouvoir travailler avec. On ne peut pas dire à un développeur, ne bloque pas, il ne sait pas, il est face à beaucoup d'outils qui bloquent, c'est très difficile de gérer son programme de cette façon. Il faut plutôt donner les API un peu haut niveau pour permettre au développeur de faire les bons choix, prendre les bonnes décisions.