Temps de lecture : 4 minutes Presque un tiers de la production alimentaire mondiale à destination de la consommation humaine est perdue. Chaque année, ce vaste gâchis représente 1,3 milliard de tonnes de nourriture. C’est pour lutter contre ce gaspillage que la startup française Comerso s’est lancée en 2013. L’entreprise propose une plateforme à destination des supermarchés et des acteurs de l’agroalimentaire pour gérer de manière fluide et sécurisée les invendus.
Tous les aspects de cette redistribution sont traités : la fiscalité, la logistique ainsi que les sujets relatifs à la donation de denrées périssables à des organisations caritatives. L’application fonctionnait jusqu’alors sur une machine virtuelle managée par un tiers. Soucieuse de reprendre le contrôle de sa plateforme technique, l’équipe de Comerso ne souhaite pas cependant avoir à s’occuper de l’infrastructure sous-jacente. Un double objectif qui conduit naturellement vers une plateforme Azure et des services tels que :
- Azure App Service,
- Azure SQL Database
- Azure Storage
- Azure Redis Cache.
Dans ce modèle, Comerso déploie son code applicatif et la plateforme Azure gère le reste, de l’infrastructure réseau à la scalabilité (capacité à tenir la charge).
Si l’objectif est clair, de nombreux points méritent toutefois de l’attention pour réussir cette transition d’une infrastructure classique vers une PaaS (Plateforme as a Service). Il est bien entendu hors de question de réécrire une application qui cumule plusieurs années de développement. Comment l’adapter à Microsoft Azure ? Quelles sont les contraintes à lever ? Explications.
3 domaines fonctionnels, 3 applications
D’un point de vue IT, la solution de Comerso peut être découpée en 3 domaines.
- La prise en charge des produits dans les supermarchés et leur livraison dans les organisations caritatives, process accompagné d’outils de pilotage et de prévision.
- L’accès à l’ensemble des documents administratifs et la gestion des déclarations fiscales.
- Le suivi en temps réel du process logistique.
À cette fin, la solution existante est composée de :
- 3 applications web fonctionnant sous IIS
- 3 applications console exécutées via l’ordonnanceur de tâches Windows
- 1 base de données SQL
Toutes les applications ont été développées avec .NET 4.5.2 et ont recours au framework Entity ou aux API ADO.net pour dialoguer avec SQL Server.
5 points à traiter pour migrer vers le cloud
Au regard de cet existant, plusieurs problèmes doivent être résolus pour réussir la transition vers Azure :
1) Les documents (images, fichiers attachés) sont stockés sur une VM utilisant les API du système de gestion de fichiers de .Net.
Avec Azure App Service, les fichiers persistants ne doivent pas être stockés directement sur la machine car Azure ne peut pas garantir qu’il s’agit toujours de la même machine. La bonne pratique consiste à externaliser le stockage, par exemple avec Azure Storage. C’est le premier problème à résoudre : faire fonctionner la solution avec Azure Storage blob.
2) Les applications web fonctionnent sur une seule VM.
Cette situation suppose que cette VM ne s’arrête jamais de fonctionner. Un pari risqué… Avec Azure App Service, il est facile de gérer le scale out (la multiplication des noeuds pour faire face à la charge). Et c’est là que survient un nouveau problème : les applications sont exploitées en mémoire ce qui n’est pas recommandé dans un environnement cloud avec des VM multiples. Il faut donc migrer le statut des sessions dans Azure Redis Cache.
3) Un historique de données conséquent doit être importé.
L’application Comerso n’est pas nouvelle et cumule de nombreuses données : certaines sont en base, d’autres sont des fichiers stockés sur le file system. Un historique à traiter.
4) L’application n’est pas pensée pour la globalisation
L’application Comerso ne fonctionne pas sur la base d’heures et de dates UTC. Une contrainte à l’heure de la globalisation pour une application moderne, d’autant plus quand elle s’exécute sur le cloud.
5) Le déploiement continu n’est pas outillé
Le dernier point concerne le déploiement. Avec l’application existante, à défaut de disposer d’outils et de process dédiés, plusieurs heures sont requises pour déployer une nouvelle version. Il est donc nécessaire de créer un véritable process d’intégration et de déploiement continus en s’appuyant sur Visual Studio Team Services.
Vers un nouveau design d’architecture
Une fois ces points identifiés, un nouveau design d’architecture est élaboré.
Plusieurs environnements sont disponibles pour le développement, les tests et la production. Trois applications web sont exécutées. Chacune dispose dans chaque environnement de son propre slot afin de pouvoir basculer rapidement en production.
Figurent aussi dans cette architecture, une base Azure SQL, un compte Azure Storage pour les blobs, un service Azure Redis Cache pour assurer le maintien des états des sessions entre les différentes machines.
> Retrouver les scripts et les modèles utilisés pour configurer les environnements et services.
Au final, 3 jours de travail avec l’équipe de Comerso ont suffi pour migrer les applications existantes vers Azure. En outre, un process de déploiement continu existe désormais pour s’assurer de la mise en production de chaque mise à jour du code source. Cet exemple montre que migrer vers Azure App Service est une opération accessible qui n’impose pas une réécriture de fond en comble de l’applicatif, loin de là même avec des contraintes liés à sa conception.
