InfoQ FR s'est entretenu avec Matthieu Joubert de l'équipe de Keepeek, une startup française spécialisée dans le traitement et le stockage du capital digital des entreprises. Ce premier article s’intéresse aux problématiques et orientations techniques de l’entreprise. Seront abordées dans un second temps les méthodes employées par Keepeek pour atteindre ses résultats.
InfoQ FR : Bonjour Matthieu et merci de nous recevoir. Pourriez-vous tout d'abord vous présenter ?
Matthieu : Matthieu Joubert, directeur technique chez Keepeek, architecte (et toujours codeur) Java depuis 15 ans, adepte de l’agilité. Créé en 2008, Keepeek développe et commercialise des solutions logicielles innovantes de gestion de contenus média s’articulant autour de 3 domaines :
- Digital Asset Management : la rationalisation de la gestion des contenus marketing et communication
- Brand Asset Management : l’harmonisation et la gestion de l’identité de marque
- Product Asset Management : l’industrialisation des flux de photos produits
Nous avons aujourd’hui plus de 250 clients issus des secteurs du E-commerce, de la grande distribution, de la mode, du tourisme, de l’industrie.
InfoQ FR : Comment s'organise Keepeek en matière d'équipes ?
Matthieu : Basé en France, Keepeek dispose de deux agences (une à Paris et une à Rennes) et est composé de 23 collaborateurs (10 à Paris et 13 à Rennes). Les équipes techniques et commerciales sont réparties sur ces 2 sites.
InfoQ FR : Sans dévoiler les secrets, pourriez-vous nous expliquer concrètement ce que fait l'application Keepeek ?
Matthieu : L'application Keepeek a pour vocation de gérer tous les contenus marketing et communication de l’entreprise, en mode SaaS ou On Premise. Elle permet de centraliser tous les contenus multimédias, de gérer leur cycle de vie, les partager avec les autres collaborateurs. Typiquement, des utilisateurs vont ajouter des reportages de photos dans l'application, puis les enrichir en métadonnées (titre, copyright…) et enfin les partager avec le reste de l'entreprise (interne, externes, partenaires...). L’application bénéficie de fonctionnalités collaboratives pour permettre à de nombreux utilisateurs d’interagir avec les contenus. En mode étendue, elle permet aux entreprise d’intégrer tout leur écosystème de la chaîne graphique : les agences de communication, les photographes, les imprimeurs, les journalistes…
Le logiciel dispose de nombreuses interfaces d’accès avec des sites responsives en HTML5, Applications mobiles, Plugin Adobe, Plugin Office, Plugin Sharepoint, API Restful. Les archi sont sensiblement identiques en SaaS et On Premise. Par contre, selon les ressources allouées à la solution, on va instancier plus ou moins de VM. Chez certains clients, on tourne sur une VM unique agrégeant tous les rôles, alors qu’en SaaS par exemple, on a plusieurs serveurs web au lieu d’un seul.
InfoQ FR : Rentrons un peu dans la technique. Quels sont les composants clients de Keepeek et comment ont-ils évolué ?
Matthieu : Coté interface back-office, nous sommes sur GWT depuis quelques années déjà. Nous avons été séduits par la communauté importante et la grande diversité de librairies annexes disponibles. Nous pouvons coder en Java à la fois sur les couches clientes et serveurs. Sur le back-office, nous faisons du sur-mesure. Nous apportons un grand soin à nos écrans. Même un écran de paramétrage CRUD que l’on peut parfois produire à la chaîne sur d’autres applications fera l’objet d’une grande customisation dans notre back-office. Cela nous demande beaucoup de temps et d’énergie, mais en retour, nous avons beaucoup moins de support à effectuer auprès de nos utilisateurs.
Nous disposons également d'un portail responsive. Pour cette partie, nous avons privilégié une technologie plus légère sur base de Wicket et JQuery. Là par contre, on est sur du templating puisque le portail peut être déployé et customisé par client. Les portails responsive sont full HTML5. Dans le back-office, nous avons utilisé dans le passé des modules flash pour les uploads et des players (zoom, vidéo, document). On est en train de terminer la migration vers des technologies HTML5 car il existe désormais des players très matures. De plus, Flash est de moins en moins bien accepté par les DSI de nos clients.
Nous proposons également d'autres dispositifs de connexion :
- Une application native iOS réalisée avec la dernière version de Swift
- Un plugin Office réalisé en natif C#
- Un plugin Sharepoint mixant une partie Java et .Net
- Un plugin à base d’Angular que nous avons décliné pour Photoshop et Flexmail
Tous ces modes de connexion attaquent la même API RESTful JSON.
InfoQ FR : Et derrière, comment ça tourne ? Quelles orientations d'infrastructure avez-vous pour répondre aux attentes ?
Matthieu : Nous sommes historiquement tournés vers les technologies Java. On tourne sur Apache/Tomcat. Nous sommes initialement partis sur une architecture SOA avec un stockage de métadonnées en SQL. Nous avons fait évoluer notre architecture rapidement pour y intégrer des moteurs d'indexation NoSQL pour la recherche et les filtrages. On a utilisé Lucene dans un premier temps. Nous continuons d'évoluer dans cette voie pour proposer des dispositifs de recherche rapides et scalables. Nous avons étudié Solr et ElasticSearch. Pour Solr, on a apprécié la proximité avec l’équipe Lucene. Pour ElasticSearch, l’écosystème est très séduisant avec des projets connexes comme Kibana ou LogStash qui sont très puissants. Notre choix s’est finalement porté vers ElasticSearch. La prochaine version majeure de Keepeek proposera une migration complète vers ElasticSearch.
Nous effectuons également du traitement des fichiers médias. L'application Keepeek transforme en permanence les images, les vidéos ou les documents pour donner à l’utilisateur le format le plus adapté à son besoin. Nous avons mis au point un système de traitement parallèle des fichiers médias pour encaisser des centaines de traitements simultanés. Ce dispositif combine un système server/node en Java et des appels aux outils de transformation natifs (Imagemagick par exemple). Cela nous garantit découplage et scalabilité sur les traitements. Côté plate-forme, on est CentOS sur notre cloud. On propose aussi des installations On Premise sur du Windows ou du Linux indifféremment.
InfoQ FR : Faîtes-nous un peu rêver. Que brassez-vous comme volume de données et qu'est ce que cela implique en termes d'architecture et de réseaux ?
Matthieu : Keepeek travaille aujourd'hui avec environ 250 clients. Au total, nous parlons de plus de 50 To, dont une bonne partie sur notre infrastructure. Cela représente des dizaines de millions de fichiers. La question de cette masse et du volume de données a toujours été dans nos préoccupations. Nous avons initialement conçu l'application Keepeek pour anticiper ce type de charge. Nous faisons évoluer notre infrastructure en permanence pour bénéficier des avancées (fort nombreuses) des hébergeurs. Nous sommes hébergés chez Claranet. On apprécie à la fois la qualité de leur suivi en production et la maturité de leur vision quand il s’agit de faire des évolutions dans l’infrastructure. Cela nous permet de plus, de disposer de datacenter situés en France. Nous étions auparavant hébergés sur des blades, un SAN et un NAS. Nous venons de terminer une migration vers des plateformes Nutanix. Ces nouvelles plateformes permettent d'assurer une très grande scalabilité avec un coût raisonnable. Nous faisons également évoluer nos dispositifs de backup en permanence car sauvegarder et restaurer des dizaines de To n'est pas chose facile. On dispose d’un espace de backup basé sur CEPH hébergé dans les mêmes datacenter que les serveurs. On a aussi un deuxième backup hébergé par nos soins.
InfoQ FR : Nous sommes tous en plein débat entre l'orientation d'architecture en mode Monolithe vs Microservice. Quelles sont vos orientations et qu'est-ce qui les guide ?
Matthieu : L’API est probablement le composant le plus important de notre écosystème. Récemment, nous l’avons entièrement réécrite pour l’amener à une maturité de niveau 3 hypermedia selon Richardson. Nos partenaires peuvent ainsi bénéficier de notre moteur DAM sans avoir besoin d’en appréhender sa complexité. Nous avons vu ainsi de nombreuses applications tierces développées, certaines sans le moindre support de notre part. Beaucoup de nos nouveaux développements comme le plugin Photoshop sont basés sur cette API.
On rencontre les deux architectures chez Keepeek. Notre back-office est de type monolithe par exemple. Notre moteur de traitement des fichiers est par contre très proche d’un microservice dans son architecture. On instance un ensemble de nodes. Chaque node définit ses capacités de traitements (photos, vidéos, document,….) et sa puissance. Ils travaillent en totale autonomie. Un node peut crasher, il reste toujours les autres nodes. Pendant les périodes de tension, on rajoute de nouveaux nodes pour effectuer plus de traitements.
On migre en ce moment plusieurs aspects de notre monolithe vers du micro service. Le moteur de recherche et de filtrage va devenir un microservice. Nos services de log d’usage médias et utilisateurs vont aussi migrer vers du microservice. On ne cherche pas forcément à opposer les deux visions. On est historiquement Monolithe, mais on reconnait que l’approche microservice est particulièrement adaptée à certains pans de notre software. Dans ces cas-là, il ne faut pas reculer devant le refactoring nécessaire. A l’inverse, souvent pour des questions de performances, le Monolithe permet de prendre des raccourcis très difficiles à effectuer avec des microservices.
InfoQ FR : Quelles tendances technologiques regardez-vous en ce moment ?
Matthieu : Au niveau interface, on est très intéressés par Angular. Côté middleware, on étudie NGinx et MariaDB. Enfin, on regarde comment faire évoluer notre BI avec ElasticSearch.
InfoQ FR : Merci Matthieu pour vos réponses.