Windows Azure Mobile Services est une bonne approche clés en main pour créer à moindre efforts un backoffice pour applications Mobile. Toutefois, sur des Backoffice complexes, Mobile Services peut se retrouver limité à cause de son syndrome “boite noire”.

Les équipes de Microsoft travaillent cependant pour limiter de syndrome, et les deux récentes annonces de Juin le prouvent bien :

• Les Custom API permettent au développeur d’écrire et de publier en node.js son propre code coté serveur, ce qui repousse considérablement les limites de Mobile Services.
• L’intégration au contrôle de code source GIT simplifie l’industrialisation et permet de tendre vers une approche “entreprise” en disposant d’un vrai référentiel de code source qui contient l’ensemble des scripts node.js créés et modifiés depuis le portail.

Si cela n’est pas suffisant, la bonne nouvelle, c’est que Mobile Services n’est en fait qu’un regroupement d’autres services Azure, il est donc assez simple de recréer la même architecture que celle proposée en s’appuyant sur Windows Azure. Ceci permet également à des développeurs ayant débutés sur Mobile Services pour des raisons de productivité de faire évoluer en douceur leur backoffice tout en reprenant le contrôle technique sur celui-ci.

En termes d’équivalence en service Azure, on peut retrouver face aux fonctionnalités d’Azure Mobile Services :

API Mobile : C’est la seule vraie difficulté de migration, recréer la couche de service du backoffice. Deux solutions sont possibles en s’appuyant sur un Service Hébergé Azure contenant un Web Role : soit repartir d’un projet node.js (officiellement supporté par Azure) et re-implémenter complètement la couche de service, soit utiliser un projet ASP.NET MVC WebAPI pour créer très simplement en .NET la couche de service à partir de la base de données.

Base de données : Mobile Services génère une base de données SQL Azure. Celle-ci peut donc être réutilisée telle quelle puis avoir son schéma qui évolue hors de Mobile Services. Aucune complexité à la consommer depuis une couche de service quelconque !

Authentification : Mobile Service est une simplification de la brique technique Windows Azure Access Control Services. ACS permet d’effectuer de la fédération de providers d’identités publiques (Facebook, google, live…) ou privée (Active Directory via ADFS). Il est donc possible de s’appuyer dans les applications mobiles directement sur ACS, sans utiliser Mobile Services comme intermédiaire (simplificateur). Ceci permet notamment de couvrir les scénarios d’authentification d’entreprise (SSO), alors que Mobile Service se limite juste aux applications grand public.

Scheduler : Le scheduler de Mobile Services n’est rien d’autre qu’une boucle infinie qui déclenche une action en intervalle régulière. En mode PaaS dans Azure, il est possible de développer l’équivalent depuis le tout début de Windows Azure en créant un projet Service Cloud contenant un Worker Role. En le développant soit même, il est possible d’aller bien sur beaucoup plus loin : de déclencher les services de manière conditionnelle ou encore d’être plus fin dans la planification (ex: une fois par jour, mais entre 1 heure et 2 heures du matin).

Push : Dans le cas du push, ce n’est pas Windows Azure qui a apporté quelque chose à Mobile Services mais le contraire ! Le push / notification était disponible à la base dans Azure uniquement dans Mobile Services. Depuis peu, cette fonctionnalité est accessible en stand-alone, en tant que brique présente dans le Service Bus, sous le nom Francisé de “Concentrateurs de Notification”

Deux choses sont à retenir :

• Azure Mobile Services est en évolution permanente, et les dernières de celles-ci tendent à augmenter la prise de contrôle technique du backoffice par les développeurs.
• Le choix d’Azure Mobile Services peut être remis en question dans le temps, sans perte de données et en limitant l’interruption de service. Cela permet à cette technologie de bien joueur son rôle “d’accélérateur de développement”.

Même si en tant que développeur, je ne suis pas fan de Azure Mobile Services (préférant toujours repartir sur une architecture que je contrôle complètement), force est de constater que cette brique joue très bien son rôle pour les équipes de développement n’ayant pas de compétences en backoffice ou souhaitant se concentrer sur les applications mobiles.