Cas d’étude : Mapwize migre une architecture Cloud de Heroku vers Azure App Service
CLOUD & INFRA

Cas d’étude : Mapwize migre une architecture Cloud de Heroku vers Azure App Service

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.

 

Cloud hybride : êtes-vous prêt ?

Comment gérer votre environnement IT à l’heure du cloud hybride ? Cinq questions – et les réponses – pour ne rien manquer de la révolution IT en cours. 

Télécharger

 

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.

 

Azure Functions

 

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.

» Script disponible ici

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.

 

Rapport Magic Quadrant de Gartner sur l’IaaS

Pour la cinquième année consécutive, Gartner positionne Microsoft comme un des leaders mondiaux en 2018 du Magic Quadrant pour l’infrastructure cloud en tant que service (IaaS).

Télécharger

 

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.

 

Architecture globale de 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