Accueil Nos publications Blog Faut-il reconsidérer les providers de BaaS comme Parse ?

Faut-il reconsidérer les providers de BaaS comme Parse ?

Les applications mobiles existantes aujourd’hui disposent, dans leur majorité, d’une infrastructure avec laquelle elles sont intimement liées. Cette infrastructure, c’est l’écosystème qui regroupe l’ensemble des dispositifs permettant à ces applications de fonctionner, depuis les services exposés, les données stockées et consommées, les notifications envoyées et reçues ou encore l’authentification déléguée, et bien d’autres encore. Souvent, il peut être coûteux de mettre en place chacune des briques nécessaires à ce grand ensemble. Et c’est ce qui a motivé l’apparition en masse de ce que l’on appelle les [Mobiles] “Backend As A Service”. Tout au long de cet article, nous reviendrons sur la notion de BaaS et prendrons un peu de recul suite à l’arrêt du provider Parse.

Qu’est-ce qu’un Backend as a Service ?

Dans la notion d’infrastructure que l’on évoquait en introduction, il y a un degré de complexité qui n’est pas vraiment visible mais qui existe. Cette complexité peut se mesurer par les ressources humaines engagées, l’architecture mise en place, les moyens financiers, les sauvegardes des données, la scalabilité, etc… Maintenant, le cloud a démocratisé cette complication, la rendant beaucoup plus accessible, nous dispensant d’infrastructure “physique”.
Le Backend as a Service est donc une plateforme qui tire avantage du cloud et composée de plusieurs briques nécessaires à des applications mobiles connectées en termes de :

  • Stockage / hébergement
  • Gestion de données / utilisateurs
  • Services mobiles
  • Notifications
  • Authentification

Ces systèmes sont autonomes mais peuvent bien entendus être liés / communiquer avec des systèmes existants. C’est courant quand on gère déjà soi-même ses données, mais que l’on souhaite utiliser des briques externes pour gérer les notifications (ou l’authentification sociale) par exemple.

Là où les BaaS vont faire la différence aujourd’hui, c’est sur leur capacité à être intégrés dans des applications mobiles et ce, peu importe les plateformes cibles.
C’est pour cela que beaucoup de ces backends proposent des SDKs, que ce soit pour Google, Apple, Microsoft, ou encore en Javascript.

Le cas de Parse

BaaS_Parse_Logo
Parse est un fournisseur de BaaS. Depuis sa création en 2011, la forte croissance de l’entreprise et son attractivité lui a valu d’être rachetée par Facebook (en 2013). Depuis, elle n’a cessé de se développer pour offrir, aujourd’hui, une infrastructure relativement robuste et simple qui plait toujours autant.

Parse reposait sur 3 piliers essentiels qui sont ses briques Core (stockage, hébergement, utilisateurs, services mobiles), Push (notifications) et Analytics.

“Reposait” puisque que, il y a quelques jours, Parse a annoncé sa fermeture tout en étant assez évasif sur les raisons ayant mené à cette décision.

Bien qu’ils aient ouvert une partie des sources de leurs produits (en particulier la partie serveur) et proposé un guide d’export de référentiel de données, il reste quand même des briques qui ne sont pas couvertes par cette fermeture et pour lesquelles il faudra trouver des alternatives (les notifications, par exemple).

Les clients mécontents ne manquent pas et on pourrait se demander s’il faut continuer à faire confiance à Facebook dans le cadre des produits qu’il peut racheter ?
Je n’ai pas de réponse concrète, mais il y a plusieurs leçons que l’on peut en tirer.

Dave Verwer, de iosdevweekly, en parle dans sa dernière newsletter et l’a bien résumé en ces mots :

It’s always a tricky balance between using a BaaS platform like Parse, or building everything yourself. We’re all aware that any service we rely on could potentially go away at any time but there is none more disruptive than your entire back end! On the other side of the argument, you could spend years building everything you need from scratch and completely custom, then have the app not gain any popularity and have it all wasted. It’s a tricky problem and there’s no right answer.

Même si l’on dispose d’un an pour migrer ses données et trouver des alternatives dont nous parlerons plus tard, il faut analyser le problème dans le fond.

Une approche pour la résolution du problème

Le point de vue que j’expose ici est strictement le mien et ne reflète nullement le point de mon employeur

J’ai déjà parlé des avantages de BaaS en introduction à cet article, citons :
* le coût (pas de maintenance et de frais d’infrastructure à gérer)
* les services proposés
* les plateformes ciblées
* facilité & rapidité d’accès, etc.

Quand on utilise un BaaS, nous signons pour une dépendance forte au service.

Un problème de dépendance forte

C’est le premier risque auquel nous nous exposons en choisissant une contrepartie en tant que service dont nous dépendrons entièrement. Et l’on retrouve deux dépendances fortes :

  • Dépendance fonctionnelle (les moyens proposés par le fournisseur du service)
  • Dépendance technique (les moyens proposés par le provider via ses SDKs mais aussi les moyens mis en œuvre par le client pour les intégrer)

Le problème avec ce type de dépendances est qu’elles imposent et dictent notre vision avec leurs propres visions.

Si la contrepartie est amenée à interrompre ses services ou à disparaître, les conséquences auront sans aucun doute des impacts non négligeables, à cause d’une dépendance.

Un manque d’isolation

Quand on a un problème avec une dépendance, la meilleure solution ne consiste pas à en changer.

Le problème de dépendance quand on le rencontre révèle un manque d’isolation, surtout dans le cadre du BaaS.

L’isolation peut intervenir à plusieurs niveaux, le plus souvent au niveau du backend lui-même, mais je parle cela dit d’aller encore plus loin. Quand je parle d’isolation, je parle de mettre en place les techniques qui permettraient de remplacer l’une ou l’autre des briques du BaaS par une autre d’un autre BaaS ou d’un système quelconque.

Mettre en place ces techniques avant d’utiliser un BaaS a assurément un coût qu’il convient de considérer dès le début et qui sera forcément rentable dans le genre de situation similaire à celle dans laquelle nous place Parse.

Reconsidérer les BaaS

Réduire les risques liés à la dépendance d’un BaaS revient quand même à analyser certains axes concernant sa stratégie ou les services mis à disposition.
* Popularité, maturité et communauté autour du service
* Capacité à déplacer ses services sur nos propres serveurs
* Accès aux sources des clients (et surtout des serveurs)

J’ai idéalisé mais, malheureusement, à ma connaissance, aucune plateforme ne propose cela.

D’où l’importance d’avoir quand même la main sur probablement d’avantage d’aspects de l’infrastructure du BaaS. Ou pas ?

Créer ou non son propre BaaS ?

Il faut l’avouer, la réponse à cette question réside dans les moyens financiers et humains dont disposent les clients, mais pas seulement. Il faut aussi prendre en compte le temps et les projets à long termes, notamment la maintenance.

La diversité des briques du BaaS offre une multitude de solutions pour les mettre en place, mais impose la nécessité d’avoir des connaissances dans chacune des briques ou des profils qui leurs sont dédiés (le stockage & la gestion des données, les services mobiles, les notifications, l’authentification déléguée, etc…), connaissances auxquelles il faut rajouter la sécurisation de chacune des briques (aspect souvent négligé malheureusement).

Cela dit, nombre de clients utilisent cette approche mixte pour garder la main sur le stockage des données, par exemple, et dédier l’authentification ou les notifications à des systèmes tiers. Et c’est le plus souvent le tiercé gagnant.

Quel BaaS choisir ?

La fermeture de Parse a suscité un engouement pour pouvoir révéler les alternatives à Parse. On y retrouve les backends classés par fonctionnalités. Vous pourrez constater que finalement, il est souvent difficile de retrouver une alternative englobant l’intégralité des besoins que nos applicatifs peuvent couvrir, mais qu’il est possible de faire ces BaaS, la plupart du temps, collaborer entre eux. En étudiant les différents choix possibles, on peut se demander s’il ne faudrait pas envisager une plateforme Cloud beaucoup plus complète.

Faut-il s’orienter vers les plateformes Cloud ?

Microsoft_Azure_MobilityJ’avoue n’avoir utilisé que Microsoft Azure (surtout parce que cela correspond aux outils utilisés par la majorité de nos clients) et pas les principaux concurrents. La plateforme comprend cela dit l’intégralité des briques proposées par Azure dans sa brique App Services.

BaaS_Microsoft_Azure_App_ServiceEn plus d’une API REST, un SDK régulièrement mis à jour est proposé pour chacune des plateformes (iOS / Android / Windows et même Xamarin). Je pourrai en parler davantage mais, cela mériterait un article à part entière.

Pour finir

Bien que leur mise en place aujourd’hui soit très facilitée, l’utilisation d’un BaaS doit être relativement bien réfléchie afin de prévenir les pires scénarios (arrêt des services) comme nous avons pu le voir.

Me concernant, j’aurais tendance, pour des raisons de coût, à privilégier les solutions complètement clé en main proposées par les prestataires tels que le regretté Parse. Bien entendu, l’utilisation d’un tel prestataire doit se faire en connaissance de cause et en réfléchissant aux techniques d’isolation pour favoriser la migration vers une plateforme ou une autre, ou alors, favoriser les solutions mixtes.

J’aime aussi beaucoup les solutions comme Microsoft Azure et ses briques mobiles. La principale raison est que j’ai tendance à favoriser les solutions tout en un, avec des briques dédiées certes, mais capables de communiquer avec le reste de mon infrastructure qui pourrait être, elle aussi, hébergée dans les nuages. Cela n’empêche bien entendu pas la mise en place des recommandations dont il était question dans cet article.