Aquarelle.com s’apprête à cueillir les microservices

Une migration vers AWS engagée dès 2012

« Maîtriser totalement notre plateforme logicielle nous permet d’être très réactifs par rapport aux demandes qui nous sont faites par les métiers. »

Si le site a démarré en misant sur sa propre plateforme IT infogérée par Atos (dont il a été le deuxième client Web, après Decathlon.fr), le groupe a opéré sa migration vers le cloud dès 2012. Nicolas Aubin, DSI d’Universal Flower, l’entité en charge de l’IT du groupe retrace ses premières années chez Aquarelle : « Depuis les débuts d’Aquarelle, nous avons voulu nous appuyer sur nos propres infrastructures. C’est un contrôle de notre infrastructure que nous avons souhaité conserver jusqu’à aujourd’hui, car maitriser totalement notre plateforme logicielle nous permet d’être très réactifs par rapport aux demandes qui nous sont faites par les métiers. Une solution préférée à celle qui consiste à s’appuyer sur des prestataires pour développer les sites ».

L’architecture logicielle a été pensée pour optimiser au maximum la réactivité de la petite équipe informatique, afin de délivrer le plus rapidement possible les fonctionnalités qui vont faire la différence de ce challenger dans la vente en ligne de bouquets. Ainsi, Aquarelle a pu proposer la personnalisation en ligne des messages accompagnant les bouquets ou encore la prise de photo du bouquet avant son envoi. « Nous avions besoin d’un socle technique qui nous permette de construire nos sites plus facilement. Dès l’origine, nous avons eu la volonté de bien isoler les parties techniques et métiers de nos sites, de la partie présentation ».

La plateforme a bien évidemment connu quelques évolutions depuis sa création, notamment avec une bascule vers les Web Services en 2003/2004, architecture qui est restée en production jusqu’en 2013, lorsque Nicolas Aubin a initié la migration de la plateforme vers Amazon Web Services. « La seule difficulté que nous avions avec notre plateforme infogérée était de faire face aux pics d’activité, comme la fête des mères. Cela nous demandait énormément de temps pour déployer des serveurs supplémentaires. Nous nous sommes tournés vers AWS essentiellement afin de bénéficier de l’autoscaling des ressources ».

L’équipe IT étant restreinte, le DSI choisit alors de migrer sa plateforme en l’état, sans chercher à faire évoluer son architecture. Les bases de données MySQL sont néanmoins basculées sur RDS, le service de bases de données managées d’AWS. Mais Nicolas Aubin a redoublé de prudence lors de cette migration : « la plateforme a été migrée telle quelle, car celle-ci est plutôt complexe avec 300 tables dans nos bases de données, et de nombreux outils de back office permettant de gérer l’activité au-delà des seuls sites Web. Cette plateforme est critique pour l’activité de l’entreprise et nous ne voulions pas nous prendre les pieds dans le tapis en voulant faire trop de choses en même temps ».

Aquarelle migre vers le framework Symfony

C’est donc ensuite que le DSI lance la seconde phase de modernisation de l’architecture, c’est-à-dire la migration des sites de front office vers le framework Symfony : « nous n’avions jusque-là pas eu recours à un framework PHP, donc nous avons redéveloppé nos sites Web afin de bénéficier de Symfony ».

Si le framework Open Source a apporté à Universal Flower un certain nombre de fonctionnalités appréciées, celui-ci a quelque peu bousculé le découpage fonctionnel de l’architecture logicielle. De plus, les web services continuaient à être exploités par les applications de backoffice.

Le DSI cherche alors à reproduire le mode de fonctionnement de ces web services dans l’environnement AWS, et, conseillé par Neoxia et Skale-5 (filiale DevOps et Cloud Services de Neoxia) qui sont intervenus dans la migration vers AWS, celui-ci s’intéresse aux microservices : « cette logique de services fonctionnels indépendants constituait déjà l’ADN de nos Web Services, donc d’un point de vue technique, la suite logique était d’aller vers les microservices qui s’intègrent plus facilement dans l’infrastructure AWS. »

Le DSI a donc demandé à Skale-5 d’aider son équipe à concevoir une nouvelle organisation fonctionnelle des applicatifs du groupe sous forme de microservices : « les microservices vont nous permettre de regrouper les données et les règles fonctionnelles métiers et éviter de retrouver des règles métiers éparpillées dans le code PHP/Symfony qui reste notre langage et notre framework principal pour le volet front ». Neoxia travaille pour sa part sur le volet développement pur de ces microservices sur AWS.

Bâtie sur Kubernetes, l’architecture cible va être mise en œuvre sur un premier projet, le redéveloppement du backoffice mis à disposition des fleuristes du réseau 123fleurs. Pour ce projet, le DSI n’a pas souhaité conserver le code source existant, mais refondre complètement une application qui datait de plus d’une douzaine d’années : « Issue d’une acquisition, cette application devait être redéveloppée. Nous sommes donc partis d’une feuille blanche pour refaire du code propre sur notre nouveau socle technique. Nous avons conservé en grande partie la structure de la base de données, mais pas le code source ».

« Nous avons mis à disposition de Neoxia les API qui leur permettent de développer la partie front de l’application, à partir de boîtes noires dans un premier temps, puis aux API raccordées aux vraies données. »

Une personne de l’équipe interne d’Universal Flower travaille sur le volet microservices depuis près d’un an maintenant, se concentrant uniquement sur la logique métier de l’application, son volet front étant de son côté confié à Neoxia : « nous avons mis à disposition de Neoxia les API qui leur permettent de développer la partie front de l’application, à partir de boîtes noires dans un premier temps, puis aux API raccordées aux vraies données ».

Pour l’heure, l’application historique de 123fleurs reste en production. La nouvelle version viendra la remplacer fin septembre 2019, avec un premier déploiement en bêta-test auprès d’une quinzaine de fleuristes. Ce n’est qu’après cette phase que l’application pourra être déployée auprès des 2 000 fleuristes de ce réseau.

Vers un déploiement progressif des microservices

Si la finalité est bien de migrer l’ensemble de la plateforme Universal Flower vers les microservices, cette migration sera progressive du fait des ressources modestes de la DSI. Le prochain chantier portera sur la gestion des communications, puis une généralisation des microservices développés avec Neoxia pour remplacer des pans complets du backoffice actuel : « un déploiement de type big bang n’était pas envisageable du fait de la taille du back office et de la criticité d’une application qui gère les clients, les produits, les commandes et la facturation vis-à-vis des fleuristes », résume Nicolas Aubin.

« Nous souhaitons améliorer notre agilité, privilégier la réutilisabilité des composants, et ne plus avoir de problématique de duplication de code dans l’architecture. »

Si l’impact d’une architecture à microservices sur la facture AWS est difficile à évaluer, de l’aveu du DSI, l’objectif de cette bascule est bien d’accélérer le développement de nouvelles fonctionnalités sur les sites du groupe : « si cette nouvelle architecture nous permet d’être plus rapides dans le développement de nos applications, nous aurons gagné. Nous souhaitons améliorer notre agilité, privilégier la réutilisabilité des composants, et ne plus avoir de problématique de duplication de code dans l’architecture ». Les différents back office vont utiliser les mêmes microservices, de même que les sites.

Dans l’architecture élaborée par Neoxia et Skale-5 pour Universal Flower, chaque microservice s’appuie sur sa propre base de données, ses propres règles métier, une approche qui impose de devoir gérer des synchronisations de certaines données, notamment afin d’alimenter le Data Warehouse du Groupe via un système de publication avec des files SQL d’AWS et des fonctions AWS Lambda, la solution serverless du fournisseur cloud américain.

Le recours aux services managés d’Amazon Web Services tels que Lambda ne semble pas faire craindre de “vendor lock-in” à Nicolas Aubin : « AWS Lambda pour moi, c’est l’équivalent des cron et crontab que nous avions depuis toujours sur Unix. C’est un service totalement managé par AWS mais le code s’exécute de façon régulière ou au moyen de déclencheurs, de la même manière que les cron que l’on avait avant. Nous n’avons pas peur de cela et bien au contraire c’est un élément d’architecture très pratique et utile car nous n’avons pas à gérer la disponibilité, l’upscale, etc. ».

Pour le DSI, le véritable point d’attention dans un tel projet de migration vers les microservices, c’est le niveau de granularité recherché : « si l’on crée un grand nombre de microservices, cela peut rapidement devenir ingérable en production. Nous ne sommes pas de la taille d’un Netflix et il nous faut être raisonnables quant au nombre de microservices que l’on va mettre en production, se limiter dans la granularité des microservices que l’on souhaite mettre en place et rester à un niveau macro ».

Après sa migration dans le cloud public et maintenant sa mue vers les microservices et le serverless, le pionnier du E-Commerce français n’a pas pris une ride.