BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Startup Architecture : R, DocumentDB et Java chez Brennus Analytics

Startup Architecture : R, DocumentDB et Java chez Brennus Analytics

Favoris

À l'occasion de Microsoft experiences '16, InfoQ FR a pu échanger avec Florent Dotto et Thomas Sontheimer de Brennus Analytics sur leur architecture technique et notamment leur stack R, DocumentDB, Java, API App sur Azure.

InfoQ FR : Bonjour Florent, Thomas, est-ce que vous pouvez tout d'abord nous expliquer le produit avant de parler architecture technique ?

Florent : Brennus Analytics développe une solution SaaS d'optimisation dynamique des prix, pour les industriels, basée sur l'analyse de données : du choix de cette politique par segment client et produit, jusqu’au calcul du prix optimal pour chaque demande de devis reçue. Nous utilisons une technologie d’intelligence artificielle permettant d’apprendre en continu le comportement des clients à partir de l’historique des données commerciales, et d’optimiser en temps réel les prix de chaque offre en prenant en compte ses coûts spécifiques. L’ensemble garantit à l’industriel une politique de prix optimale et toujours en prise avec les évolutions du marché.

InfoQ FR : Pouvez-vous nous décrire le use case global du produit, et comment l'architecture en découle ?

Florent : Alors déjà le use case du produit, c'est de fournir une solution industrielle, un accès qui permet à leurs équipes commerciales de faire des quotations à des demandes de devis. Donc les équipes commerciales reçoivent des demandes de quotations de clients, elles doivent fixer un prix à proposer à leur client. Quelque part, notre système vient juste s'intégrer au processus de pricing de ces équipes commerciales, et la valeur ajoutée, c'est que le prix qui va être calculé va prendre en compte des historiques, enfin des données, un historique de données de notre industriel, pour modéliser le comportement, la probabilité que le client accepte le deal à un certain prix qui va être proposé, c'est ça qui va nous permettre de calculer un prix optimal pour maximiser l'espérance de marge de l'industriel pour chacun des deals en temps réel.

Donc la problématique qu'on a c'est que l'industriel puisse uploader, ou qu'on puisse récupérer les données de notre industriel sur notre serveur, qu'on puisse travailler avec ces données là pour modéliser le comportement du client, qu'on puisse aussi calculer les notions de marge et de coût de notre industriel, et une fois qu'on a tout ça, qu'on fasse de l'optimisation pour croiser les deux courbes et sortir un résultat. Il faut ensuite, ce résultat, l'afficher, donc là c'est une app web, pour simplifier on a pu fixer un navigateur qui soit Chrome. Et la problématique qu'on avait initialement, c'est qu'on ne savait pas si les industriels seraient OK pour que ce soit en SaaS, initialement on se disait qu'il fallait qu'on soit déployé aussi bien sur Azure, puisqu'on avait choisi de travailler avec eux, ou chez eux en local. Donc c'était une première approche.

La seconde, c'est qu'au final on ne voulait pas avoir à gérer une infrastructure physique, car ça présente plus d'inconvénients que d'avantages pour nous. Et justement Azure permet de ne pas s'embêter avec ça. Donc autant l'utiliser.

InfoQ FR : Vous avez commencé il y a combien de temps ?

Florent : Les réflexions ont commencé il y a... 10 mois, et on a commencé à implémenter il y a environ 8 mois, vers février 2016.

InfoQ FR : Comment sont structurées les différentes parties du système ?

Thomas : L'application se compose des éléments suivants :

  • un frontend déployé sur App services (Web App) ; implémenté avec Angular2 en utilisant Swagger pour générer le code client de l'API REST,
  • une API REST déployée en standalone sur App services (API App) ; implémentée avec Sparkjava pour le service, Jackson pour le JSON et JWT pour l'authentification,
  • un cœur d'analyse déployé sur une VM ; actuellement implémenté en R et servant une API avec FastRWeb, on travaille à son remplacement par une version intégrant la technologie AMAS avec Sparkjava pour servir l'API,
  • une base DocumentDB avec support du protocole MongoDB à laquelle l'API REST et le cœur d'analyse accèdent avec Jongo.

Thomas : Et en termes d'évolution, on était pris au début plutôt sur de l'IaaS pour utiliser Azure, donc déployer des machines virtuelles et ensuite déployer une webapp en Angular, et qui ensuite allait taper directement sur des VM qui elles déployaient à la fois une API, et en back-end derrière un serveur de calcul, qui est un serveur R.

Petit à petit, on a fait évoluer cette architecture pour profiter justement d'Azure au maximum et donc pousser le plus de choses possibles en Platform as a Service, donc notre API, ce qui était à la base déployée sur une machine virtuelle, on est en train de la migrer vers une API App qui nous permet finalement d'exposer au front-end toute l'API de notre application sans avoir à gérer la machine virtuelle, sans avoir la maintenance du système d'exploitation, les mises à jour, ce genre de choses. Et gérer aussi la redondance.

InfoQ FR : Vous tirez parti de plus en plus de services managés, on parlait de l'API ; est-ce qu'il y a d'autres exemples de choses que vous avez, comme ça, migrées, ou que vous pensez migrer à un moment ?

Thomas : Non, c'est principalement sur ce point là, après on va utiliser de plus en plus les fonctionnalités de ces services, à la fois au niveau front-end pour ce qui est du déploiement à travers des slots de déploiement, plutôt que de déployer plusieurs web applications, l'idée c'est de pouvoir déployer la même web application et ensuite de faire des switchs entre les slots pour avoir des déploiements plus fluides. Et après sinon, de toutes façons on prévoit quand même de rester sur un serveur R pour tout ce qui est analytique, l'idée ça va être de déployer notre propre technologie, qui elle est développée en Java et qui nécessite des ressources quand même relativement importantes, et donc ça on va pas pouvoir le déployer sur des App Services a priori.

On pense rester pour cette partie là toujours sur une sorte de machine virtuelle, sachant que ce qu'offre Azure là-dessus, c'est intéressant pour nous, c'est la possibilité d'avoir un gateway entre le réseau virtuel sur lequel sont déployées les machines virtuelles, et l'App Service qui fournit l'API finalement, et qui nous permet d'avoir une connnexion sécurisée en HTTPS, plus que sur notre point d'entrée qui est notre API qui est déployée comme une application, un App Service, et ensuite tout se passe sur un réseau virtuel qui donc est sécurisé et qui nous permet de ne pas gérer ça.

InfoQ FR : Pour les données clientes, avez-vous un tunnel vers la data source client ou est-ce que c'est une copie ?

Florent : Pour l'instant, c'est une copie. A terme, il faudra que ce soit un tunnel mais pour l'instant, c'est une copie.

InfoQ FR : Qu'est-ce que vous utilisez comme storage ?

Florent : Nous utilisons DocumentDB.

Thomas : Ensuite, pour la partie R, c'est un snapshot qu'on utilise aujourd'hui. L'API a elle un accès direct à DocumentDB, ce qui nous permet pour de la navigation de ne pas avoir à passer par notre serveur R. A terme, notre technologie qui sera déployée sur une machine virtuelle avec la partie Java pourra directement interroger la base de données, là on prévoit d'avoir une connexion directe. L'idée étant de ne pas dupliquer d'accès aux données, mais de passer par le même pipe.

InfoQ FR : Utilisez-vous R en interactif ou en batch pour générer des sortes de prédiction ?

Florent : Les deux. Tu peux expliquer Thomas ?

Thomas : C'est les deux effectivement, c'est-à-dire qu'on calcule des courbes d'acceptabilité.

En fait pour chaque produit que notre client va pouvoir proposer, on va pouvoir calculer des courbes d'acceptabilité et leurs caractéristiques (c'est quelque chose qu'on va calculer en batch), et par contre, une fois qu'on aura fait ces calculs-là, on va pouvoir les interroger directement en fonction des caractéristiques qui peuvent varier, en fonction des demandes de produit.

Florent : En fait, dans le process métier, les utilisateurs importent une demande de devis. A ce moment-là, lorsque c'est chargé sur notre système, c'est là qu'une surface d'acceptabilité est calculée pour ce devis-là, et puis voilà, c'est fait. Et ensuite lorsque l'utilisateur a chargé son devis, il va voir ses prix optimaux, et on peut jouer avec en fait, sur chacun des produits, le système peut recalculer en temps réel, à la volée, les courbes d'acceptabilité réelles qui sont associées au prix et à la quantité du produit, car l'utilisateur peut changer la quantité, ce qui va changer la valeur de la courbe en fonction du prix au kilo. Le prix au kilo varie en fonction de la quantité demandée.

Donc en fait, on fait un prix batch, on calcule une partie du problème au chargement, puis ensuite on calcule une autre partie du prix à la volée parce qu'on a "extrapolé" les paramètres de la courbe, et on peut calculer à la volée la valeur à cet endroit-là.

InfoQ FR : Et en termes de visualisation de tout ça, pouvez-vous nous décrire votre front-end ?

Florent : On a une appli Angular. Pour l'instant, c'est pas notre métier, notre valeur elle est dans l'algo, et pour l'instant, les clients qu'on a, ce sont des applications métier et ils travaillent avec Excel, donc dès qu'on a un truc un peu mieux qu'Excel, ça a une forte valeur ajoutée, et ça suffit. On sait ce qu'il faudrait faire pour bien le faire, mais on a pas mis de temps là-dessus, donc on a de l'Angular, on a des tableaux, des cellules et les personnes peuvent naviguer. Bon là, on utilise le minimum dont on a besoin d'Angular pour pouvoir travailler.

On est passé à Angular 2 récemment pour effacer un peu de dette technique, et résoudre des petits problèmes. On utilise une librairie particulière qui s'appelle PrimeNG. On a un petit souci, c'est que les gars sont habitués à travailler sous Excel, donc on clique sur une cellule et tout est sélectionné automatiquement à l'intérieur de la cellule, une sélection all, et donc ils peuvent faire directement une sélection et copier-coller. Ça, en fait, ça fonctionne pas dans la librairie PrimeNG, c'est bête mais ça fait un changement d'habitudes, ça fait perdre du temps car les gars sont toujours en train de faire des copier-coller. C'est un truc, en passant sur Angular 2, on a des chances de pouvoir l'adresser, donc on est passé dessus et on va chercher comment addresser ce problème.

InfoQ FR : Et la migration Angular 1 / JavaScript vers Angular 2 / TypeScript, ça a été simple ?

Florent : Angular 2, on a migré en deux ou trois jours. Thomas ?

Thomas : Oui, le passage de Angular 1 en Angular 2 a été fait en moins d'une semaine.

Florent : Après, on n'avait pas d'interface compliquée, il n'y avait pas beaucoup de code. Il y a trois pages avec peu d'interactions.

InfoQ FR : Comment vous fonctionnez en terme de CI ?

Thomas : En fait, on utilise Jenkins, forcément classique, qu'on a couplé avec SonarQube qui nous permet d'avoir des métriques. Ce à quoi on est passé récemment, comme on est sous Eclipse, c'est utiliser le plugin SonarLint, c'est le dernier plugin sorti par SonarQube, et qui permet d'avoir de l'analyse de code en direct, de ne pas avoir besoin de déclencher toute la chaîne pour avoir un retour, c'est quelque chose qui est vraiment très agréable.

Et aussi des projets mavenisés, et dès qu'on fait des commits sur Git, c'est récupéré par Jenkins, qui nous fait tout le passage des tests. Pour l'instant, on fait pas encore de déploiements automatisés, c'est la prochaine étape. Le but étant d'automatiser au maximum et de réduire les temps à chaque fois entre ce que le développeur va coder et le retour qu'il pourra avoir des tests utilisateurs.

Florent : Après, on a dupliqué les machines pour pouvoir être organisé avec un déploiement blue/green, on travaille avec une duplication de code de la version pour les clients, et ensuite en fin de sprint on bascule.

InfoQ FR : Donc aujourd'hui, votre CI est orientée qualimétrie, et question repository manager ?

Thomas : Non pas encore, c'est pareil : c'est dans les tuyaux, ça fait partie des choses à faire, sur notre expérience précédente on avait utilisé un Nexus, la question se pose là de prendre un Artifactory ou de repartir sur un Nexus.

InfoQ FR : Aujourd'hui, vous avez des "Data Scientists" dans l'équipe ?

Florent : On a tous un profil mixte, même moi j'ai un diplôme en intelligence artificielle, Thomas aussi. Donc on est une grosse équipe en intelligence artificielle, avec des profils développeurs web, développeurs tout ce que tu veux, et on a même un data scientist spécialisé en biologie. On est bien armé là-dessus, il n'y a pas de souci !

On a tous aussi une expérience entreprenariale importante. Thomas et les autres ont travaillé dans une autre boîte, qui utilisait la même techno qu'on a validé sur notre projet, et là on les a motivés pour repartir sur un nouveau projet, en changeant le paradigme business parce que le leur était pas suffisamment efficient. Donc on repart là-dessus, on y croit. Initialement, le business était on fait des applis dédiées aux problématiques de chaque client, mais ça ne crée pas de récurrent. Donc là on veut créer du récurrent sur un produit SaaS.

InfoQ FR : Merci Florent et Thomas !

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT