Xamarin et le backend

Les applications mobiles, donc de surcroît celles écrites en Xamarin, ont besoin d’accéder à un backoffice, socle des données. En effet, toute application mobile, et surtout en mode B2B, ont besoin d’accéder aux données de l’entreprise. Le monde de la mobilité apporte son lot de spécificités. Par exemple, il est très difficile d’anticiper le succès d’une application mobile que ce soit le nombre de téléchargements ou l’usage qui en est fait. Il faut donc mettre en place un backend scalable qui s’adapte au besoin de l’application, à la hausse comme à la baisse.

Anatomie d’une application mobile

Une application mobile en standard n’est ni plus ni moins qu’un client riche qui invoque des services Rest/Json.

Certaines études montrent qu’une application mobile c’est 80% d’appels de service. Face à ce constat, il convient d’étudier les enjeux d’une telle application :

1. Disponibilité
2. Scalabilité
3. Performance
4. Sécurité

Disponibilité

La disponibilité d’une application reste un élément clé. Qu’est-ce que cela veut dire ? Au vu de l’anatomie d’une application mobile, la disponibilité repose essentiellement sur celle de son backend. Le Cloud, et en particulier Microsoft Azure, apporte un certain nombre de réponses.

Tout d’abord, cette plateforme Cloud a été conçue pour gérer les pannes, on parle de « Design for failure », c’est-à-dire que la plateforme va détecter en automatique une panne matérielle et redéployer les services en minimisant le downtime (grâce aux multi-instances et la redondance à tous les niveaux, y compris matériel, rack, …). Ainsi Microsoft Azure est capable de proposer des SLA de 99,95%, bien plus que ne pourrait proposer une entreprise on-premises. L’automatisation est également un atout fort pour votre backend car vous pouvez à tout moment redéployer vos services sous quelques minutes pour corriger un bug, pour revenir sur une version n-1, etc, … Pour finir, Microsoft Azure propose également des solutions de réplication pour anticiper tout incident. Cette réplication peut être mise en place entre deux datacenters d’une même région, comme par exemple entre West Europe et North Europe ou demain entre Central Europe et South Europe J.

Mais mettre en place une architecture hautement disponible a un coût selon le niveau de service souhaité comme le montre le graphique. Il convient alors de trouver le bon curseur entre le niveau de disponibilité souhaité, le budget et la criticité de votre application. N’oubliez pas l’utilisateur d’applications mobiles est un zappeur ! Il n’hésitera pas à utiliser une application concurrente si la vôtre est trop instable.

Parmi les solutions proposées par Microsoft Azure, on peut citer Azure Site Recovery qui permet de mettre en place un Plan de Reprise d’activité (PRA) ou Traffic Manager qui permet de router vos appels de service entre deux datacenters si l’un d’eux est défaillant à cause d’un problème lié au datacenter ou à votre application.

Scalabilité

L’intérêt d’un backend dans la Cloud réside principalement dans la capacité du Cloud à fournir des solutions de scalabilité, quelles soient manuelles, programmées (notamment dans des scénarios comme les soldes ou les fêtes de fin d’année) ou automatique pour absorber des pics imprévisibles. En effet, certaines applications vont avoir des succès fulgurants grâce notamment au marketing viral, et doivent avoir une infrastructure capable de s’adapter rapidement pour supporter les pics de charge. Quand on parle de scaling ou d’élasticité, on parle de « scale up » (scalabilité verticale), augmenter la capacité d’une ressource donnée ou de « scale out » (scalabilité horizontale), augmenter la capacité en rajoutant des ressources.

Le Cloud va permettre de ne pas investir en amont dans la construction d’une architecture surdimensionnée dans le cas nominal car les objectifs du marketing sont souvent ambitieux et la DSI va se rajouter une marge de sécurité car elle devient responsable de l’architecture en place. De plus, le Cloud sera capable de réduire l’infrastructure après un pic de charge pour revenir au cas nominal. De par son modèle économique « Pay-as-you-go », basé sur l’utilisation des ressources réellement utilisées, placer son backend dans le Cloud va apporter de véritables gains.

Performance

La performance est également cruciale dans un projet mobile. Certes, il faut utiliser côté client une technologie performante comme Xamarin mais la performance est également une question d’architecture logicielle et technique. Certes il faut que les services REST appelés par l’application répond de manière performante en quelques millisecondes, mais quid des services on-premises peu scalables, voire pas du tout ? La réponse est amenée par la mise en place de patterns d’architecture comme par exemple :

• Le Fire&Forget qui consiste à appeler un service REST sans attendre son retour, utilisable dans certains cas fonctionnels. Typiquement un service de prise de commande « Order » répond à ce pattern, c’est avant tout une question de responsabilité entre l’appelant et l’appelé.
• Le Caching : mettre en place un cache distribué améliore fortement les performances d’un service REST. Un service qui retourne une liste de produits peut très facilement être mis en cache (reste à définir la politique de révocation du cache).
• CQRS : ce pattern permet d’isoler l’écriture et de la lecture dans une base de données. 80% des appels de service concernent des accès en lecture donc les besoins ne sont pas les mêmes en termes d’architecture. Attardons-nous un peu sur ce pattern, trop peu utilisé mais qui apporte de véritables réponses.

Le schéma suivant montre un exemple simplifié de ce pattern.

On utilise la puissance du Cloud pour héberger une base de données (serveur esclave) optimisée pour la lecture des données (point de consommation). Que veut dire optimisée ? On va en fait se permettre de dé normaliser la base de données afin d’accélérer les temps de traitement des requêtes SQL. Cela simplifie le plan d’exécution. On va également utiliser un serveur plus « costaud » pour absorber le nombre de requêtes cibles. Ensuite les requêtes d’écriture s’exécuteront sur un autre serveur dit maitre (point de vérité). Dès que la base de données sur ce serveur est mise à jour suite à un insert, update ou delete, un trigger va alimenter un bus de messages avec l’opération à effectuer sur le serveur esclave afin de le synchroniser. On s’autorise un delta de quelques secondes entre les deux bases de données, ce qui est acceptable dans un grand nombre de scénarios.

Il existe d’autres patterns possibles pour optimiser les performances, nous n’avons décrit ici que les principaux.

Un aspect lié plus ou à moins à la performance est la gestion du offline. En effet, la bande passante entre l’application et le backend n’est pas constante et on peut souffrir d’effet tunnel assez réuglièrement (malgré la prolifération des antennes). L’utilisateur mobile n’est pas patient, il faut donc lui proposer la meilleure expérience et ne pas bloquer l’application en cas de coupure réseau. On mettra donc en place un pattern pour gérer le offline comme par exemple écrire en local sur le téléphone une mise à jour de données et attendre le rétablissement d’une connexion pour mettre à jour le backend.

Sécurité

On pourrait écrire un article complet sur le sujet de sécurité voire un livre blanc sur ce sujet ! Sécurité applicative, sécurité de l’infrastructure, sécurité des échanges, etc, etc…. Intéressons-nous brièvement sur la sécurisation des appels de service. Dans un grand nombre de scénarios, on réutilise les services développés en interne dans le SI, mais on doit les ouvrir sur le « monde extérieur », on parle de dépérimétrisation du SI.

Il faut donc les sécuriser. Plusieurs solutions s’offrent à nous dont l’utilisation d’une solution « API Management » qui en plus de la sécurisation va nous offrir certaines fonctionnalités intéressantes comme la transformation de protocoles SOAP en REST et de messages de XML en JSON ainsi qu’un référentiel se services et de l’analytique sur l’utilisation des services (quotas, abonnements, usage, …). L’API Management sécurisera les services via des mécanismes comme des certificats, l’utilisation de protocoles comme OAuth (couplé ou non à un active directory).

Conclusion

L’utilisation d’un backend dans un Cloud n’est pas une obligation mais très généralement nécessaire voire indispensable pour vous apporter une véritable plus-value sur les aspects de scalabilité, performance, sécurité et disponibilité : enjeux d’un projet de mobilité. A vous de construire l’architecture logicielle et technique en fonction de vos besoins et problématiques mais n’oubliez pas qu’une application Mobile de qualité passe par un développement de qualité mais également par la mise en place d’un backend de qualité également.