Cas d’étude : Mapwize migre une architecture Cloud de Heroku vers Azure App Service
Temps de lecture : 5 minutes
Publié le 12 septembre 2017
Des plans, de la navigation et des applis qui vous guident dans la rue ou les transports : de nombreuses solutions facilitent déjà les déplacements. Mais comment s’orienter à l’intérieur même d’un bâtiment ? C’est la question à laquelle répond la startup française Mapwize.
Qu’il s’agisse de guider des patients dans un établissement de santé ou des clients dans un magasin, Mapwize décline des services autour de la géolocalisation intra-muros. Au cœur de la solution, un moteur d’orientation qui tient compte des étages, des escaliers, des ascenseurs ou encore des passerelles pour fournir à l’utilisateur le trajet le plus court vers sa destination. Des services que Mapwize propose aux professionnels via une app cross-plateforme et un SDK.
Née dans le cloud, la startup créée en 2014 est implantée à Lille, plus précisément au sein de l’accélérateur EuraTechnologies, et à Boston, au sein du hub French Tech. Microsoft accompagne Mapwize depuis septembre 2015, date de son adhésion à Bizspark Plus.
Un code trop complexe pour la petite équipe de Mapwize
Un accompagnement bienvenu : avec la montée en charge de ses activités et l’enrichissement de ses fonctions, Mapwize rencontrait des difficultés avec son architecture IT existante. Les solutions étaient conçues autour d’une application web monolithique sur Heroku, gérant toutes les fonctions : le site web public, les API et même le service de raccourcissement des URLs. Avec plusieurs limites à la clé :
- la complexité atteinte par le code, ce qui mettait en péril sa maintenance par une petite équipe ;
- toute mise à jour, même mineure, supposait de redéployer tout le système ;
- Il devenait de plus en plus difficile de « fine-tuner » l’architecture pour améliorer la performance globale.
En outre, pour ingérer les données en provenance des clients (nouvelles cartes, liste de salles), l’équipe devait développer, pour chacun d’entre eux, des connecteurs spécifiques . Et pour éviter de polluer les API principales avec ces cas spécifiques, il fallait trouver un moyen d’isoler ce code. Enfin, avec des clients en Europe mais aussi aux Etats-Unis, Mapwize devait déployer une solution « globale ».
La solution ? Scinder l’application
Scinder l’application monolithe en différentes parties s’est imposé comme une évidence. Pour chaque segment, une solution technique a été identifiée.
- Azure App Service pour héberger les multiples services web sans avoir à gérer l’infrastructure sous-jacente
- Azure CDN pour accélérer le déploiement global
- Azure Functions pour exécuter le code spécifique à chaque client
Regardons en détail chacun de ces sujets.
Azure App Service pour héberger les multiples services de l’application
Azure App Service repose sur la notion d’App (Web App, Mobile App et API App) qui représente une application logique et Azure Service Plan, qui agrège les ressources physiques utilisées. Avec ce modèle, plusieurs apps peuvent s’exécuter dans un seul plan et partager ainsi des ressources pour maîtriser les coûts.
Pour en tirer le meilleur parti, les développeurs de Mapwize ont découpé leur code sous la forme de services indépendants :
- Le site web public statique généré via Jekyll (écrit en Ruby)
- L’API, utilisée notamment par les apps mobiles et le SDK – et développée en Node.js
- Le service de carte qui restitue cartes et données de localisation maps.mapwize.io
- Le « shortener » d’URL : mwz.io
- Et enfin, Mapwize Studio, le back office d’administration
Chacun de ces services peut être exécuté comme une app indépendante sur Azure App Service. Avec ce dernier, Mapwize peut aussi profiter du déploiement continu de Github, combiné avec la notion de slot de déploiement. Avec ces deux fonctions, la dernière release d’une application d’une branche principale peut être déployée automatiquement sur Azure App Service, dans un slot de pré-production. Si l’équipe est satisfaite du résultat, un swap de slot peut être opéré afin que les utilisateurs bénéficient de cette nouvelle release.
Une fonction liée à Azure App Service concerne le script de déploiement et notamment la possibilité de le customiser. Le script par défaut sait comment gérer des packages Node.js ou une application Core .Net. Cependant, comme Ruby n’est pas officiellement supporté par Azure App Service, ce dernier ne sait pas comment « builder » une application Jekyll. La customisation du script de déploiement permet de télécharger automatiquement Ruby, de l’installer ainsi que toutes ses dépendances sur l’instance App Service, puis de lancer la génération du site statique.
Azure Fonctions pour héberger le code spécifique à chaque client
Le code, on l’a dit, doit être écrit spécifiquement pour certains clients. Et comme Mapwize ne veut pas gérer d’exception dans ses API, une solution a été trouvée pour exécuter ce code dans des environnements distincts : il est exécuté seulement quand des événements spécifiques se produisent ou sont planifiés.
Azure Functions fournit des fonctions de traitement « serverless » et fonctionne dans un mode événementiel.
Via Consumption Plan, la montée en charge suit la consommation effective des ressources – les utilisateurs ne payent donc que les ressources consommées. Au lieu d’utiliser Consumption Plan, l’équipe Mapwize a choisi de déployer ses fonctions dans le App Service Plan qu’elle administre, afin de maîtriser le timeout et de garantir que les fonctions présentant un cycle de vie long peuvent s’exécuter sans interruption. De fait, en utilisant App Service Plan pour héberger des fonctions, celles-ci fonctionnent dans des VM dédiées. Il est du coup possible d’intervenir sur le paramétrage du timeout.
Azure CDN pour accélérer la performance globale
Les utilisateurs Mapwize peuvent être connectés au service depuis n’importe quel point de la planète. Pour fournir la meilleure performance possible, une architecture globale est requise. Avec ses 38 régions, Azure apporte sur ce terrain un avantage significatif.
Le premier scénario consiste à utiliser un service de CDN (Content Delivery Network) pour réduire les temps de chargement. Pour construire ce CDN, Microsoft travaille avec Verizon et Akamai afin de proposer les meilleurs options à ses clients ou même d’équilibrer la charge entre de multiples CDN.
Mapwize était notamment intéressée par la possibilité de recourir à HTTPS avec un domaine spécifique sur Azure CDN. Le protocole a donc pu être activé en quelques clics sans s’inquiéter de la gestion des certificats et sans coûts additionnels. En outre Azure CDN est fortement intégrée avec les autres services Azure tels que Azure Storage ou Azure Web App – tous deux utilisés par Mapwize.
À l’horizon, Azure App Service sur Linux
En exploitant de multiples Web Apps sur Azure App Service and plusieurs Azure Functions en lieu et place d’une application monolithique sur Heroku, Mapwize bénéficie désormais d’une architecture orientée microservices sans avoir à gérer un orchestrateur tel que Kubernetes ou Docker Swarm. Résultat, le déploiement continu est devenu une réalité.
À l’avenir, l’équipe utilisant des environnements Linux, la possibilité d’exécuter des services sur Azure App Service sur Linux changera la donne et contribuera à rendre les process encore plus fluides.
À voir aussi » Voir les scripts et d’autres détails techniques
