Dé­ve­lop­pez un backend per­son­na­lisé avec Backend as a Service

Le software as a Service ou SaaS fait déjà plei­ne­ment partie du décor du monde in­for­ma­tique. Cette ex­pres­sion désigne les logiciels qui peuvent être utilisés via une connexion Internet, sans que le recours à une version locale soit né­ces­saire. De nouveaux services dans le Cloud sont également en pleine expansion dans des domaines tels que le dé­ve­lop­pe­ment Web. Dans cet article, nous prêtons une attention par­ti­cu­lière à un de ces domaines : le backend as a Service.

Le backend as a Service fait partie du cloud computing et renvoie à une in­fras­truc­ture backend hébergée sur la base de laquelle des dé­ve­lop­peurs peuvent ra­pi­de­ment et fa­ci­le­ment con­fi­gu­rer un backend. L’avantage est que les dé­ve­lop­peurs n’ont pas besoin de pro­gram­mer l’in­fras­truc­ture tout entière pour une ap­pli­ca­tion Web et peuvent se con­cen­trer sur la con­cep­tion du frontend. Les dé­ve­lop­peurs frontend peuvent également con­fi­gu­rer un serveur fonc­tion­nel en quelques étapes seulement.

Les solutions BaaS con­tien­nent un large éventail de fonctions dif­fé­rentes telles que des mises à jour au­to­ma­ti­sées du backend, des bases de données gérées, l’au­then­ti­fi­ca­tion uti­li­sa­teur et les con­nexions aux réseaux sociaux.

Parmi les autres exemples de dé­ve­lop­pe­ment sur le Cloud, outre le Baas et le Saas, on retrouve le Function as a Service (FaaS).

La manière dont la version backend fonc­tionne est similaire à la manière dont on héberge un site Web. Le four­nis­seur du BaaS livre l’ap­pli­ca­tion avec dif­fé­rentes fonctions, de sorte que les dé­ve­lop­peurs puissent combiner les données dis­po­nibles en vue de créer une sau­ve­garde in­di­vi­duelle. Les dé­ve­lop­peurs accèdent ensuite à la con­fi­gu­ra­tion du backend via des in­ter­faces émises par le four­nis­seur de service à l’aide d’APIs ou d’une interface REST et con­çoi­vent l’ar­chi­tec­ture de l’ap­pli­ca­tion Web désirée comme demandé.

Pour les four­nis­seurs plus im­por­tants, une ins­crip­tion est suf­fi­sante pour se lancer avec un package de démarrage gratuit. Selon le four­nis­seur que vous choi­sis­sez, il est possible que vous puissiez vous inscrire à l’aide de votre compte Facebook ou Google. Parmi les étapes d’ins­crip­tion gé­né­riques, on retrouve la sélection de la première ap­pli­ca­tion et de la pla­te­forme cible désirée, par exemple, HTML5, iOS, ou Android. La solution BaaS génère ensuite des clés API et, pour certains four­nis­seurs, des bi­blio­thèques Ja­vaS­cript sont créées et des fonctions standard ad­di­tion­nelles sont définies.

Les dé­ve­lop­peurs experts n’auront en général pas besoin du moindre en­traî­ne­ment pour con­fi­gu­rer le backend. Con­fi­gu­rer le backend via BaaS est simple et rapide.

Le Backend as a Service peut sim­pli­fier et accélérer le dé­ve­lop­pe­ment d’ap­pli­ca­tion. Mais le BaaS n’est pas né­ces­sai­re­ment le choix adéquat pour chaque scénario.

• Le principal avantage de cette solution est la con­fi­gu­ra­tion simple des fonc­tion­na­li­tés du backend. En quelques clics seulement, vous pouvez créer, par exemple, des modèles pour des tableaux sur le serveur sans que les dé­ve­lop­peurs aient à se soucier d’une connexion à la base de données.
• Le fait que la main­te­nance du backend relève de la res­pon­sa­bi­lité du four­nis­seur de service constitue un autre avantage.
• Les solutions BaaS peuvent être basées sur le Cloud, ce qui signifie que les in­fras­truc­tures peuvent être gérées in­dé­pen­dam­ment du lieu et du serveur.
• Par ailleurs, il n’est plus né­ces­saire de faire appel à des dé­ve­lop­peurs backend attitrés, ce qui fait de la com­mu­ni­ca­tion souvent chro­no­phage entre le backend et le frontend un lointain souvenir, et permet d’éco­no­mi­ser du temps et de l’argent.
• Étant donné que les modèles BaaS fonc­tion­nent ma­jo­ri­tai­re­ment sur le principe du pay-as-you-use (selon l’uti­li­sa­tion), les uti­li­sa­teurs paient pour les con­tin­gents qu’ils demandent. Les four­nis­seurs ont tendance à proposer des packages de dif­fé­rents niveaux (si­mi­laires aux packages d’hé­ber­ge­ment), de sorte que les uti­li­sa­teurs puissent avoir un aperçu des coûts en amont. Le fait que les con­tin­gents soient gérables est ce qui rend les solutions de Backend as a Service adaptées aux petites en­tre­prises qui ne sont pas en mesure d’im­plé­men­ter leur propre dé­ve­lop­pe­ment backend du fait de leurs res­sources limitées.
• La sca­la­bi­lité constitue un facteur décisif en ce qui concerne les ap­pli­ca­tions Web et peut avoir un impact majeur sur les coûts. Au premier abord, le Backend as a Service présente un avantage, dans la mesure où le passage d’échelle et le trai­te­ment relèvent de la res­pon­sa­bi­lité du four­nis­seur de BaaS ou sont spécifiés par le four­nis­seur et peuvent être menés à bien au­to­ma­ti­que­ment. Cela signifie que le serveur n’a pas besoin d’être mis à niveau ou migré ma­nuel­le­ment. Selon le type et le domaine d’ap­pli­ca­tion, les packages peuvent inclure des fonctions standard, telles que le fait d’envoyer des messages de push, de couvrir iOS et Android, et de donner accès à des fonctions en lien avec les réseaux sociaux sur Facebook et Twitter.

• En con­sé­quence du point exposé ci-dessus, des coûts imprévus peuvent émerger du fait du passage à l’échelle au­to­ma­tique si, par exemple, le nombre de requête entrantes et les quantités de stockage de données demandées sont inconnus ou excèdent de loin les valeurs estimées. Par contraste, les capacités et les prix associés sont connus en avance avec des serveurs dédiés. Les coûts du BaaS au-delà d’un stockage basique sont plus durs à estimer à l’avance, ce qui rend difficile de comparer les coûts.
• Les aspects liés à la sécurité, par exemple, sous la forme du stockage régulier des données issues du serveur, varient d’un four­nis­seur à un autre. Les uti­li­sa­teurs doivent com­prendre bien en amont quels sont les cycles de stockage des four­nis­seurs de BaaS, pour s’assurer que les données sont sau­ve­gar­dées aux in­ter­valles requis, y compris les sau­ve­gardes en­clen­chées en cas d’échec du serveur. Ren­seig­nez-vous auprès du four­nis­seur à l’avance pour savoir combien de temps après un échec un serveur est à nouveau uti­li­sable et quelles données sont sau­ve­gar­dées en cas d’échec. Là où des données uti­li­sa­teurs sont col­lec­tées et traitées, protéger les in­for­ma­tions sensibles se doit d’être une priorité absolue.
• Une autre limite émerge lorsque l’on passe d’un four­nis­seur de Backend as a Service à un nouveau four­nis­seur de service. Ceci est dû au fait que les four­nis­seurs ont recours à leur propre interface serveur et leurs propres kits de dé­ve­lop­pe­ment logiciel, et qu’ils stockent par con­sé­quent les API, les pilotes et les pro­to­coles réseaux à dif­fé­rents endroits. Dans ce cas, modifier l’adresse d’un serveur ou rediriger les requêtes entrantes n’est pas suffisant. De plus, il existe dif­fé­rentes approches d’im­plé­men­ta­tion que les dé­ve­lop­peurs peuvent préférer. Un backend a souvent besoin d’être à nouveau im­plé­menté lorsque l’on change de four­nis­seur.
• La lo­ca­li­sa­tion des serveurs a tendance à différer d’un four­nis­seur à l’autre. Ceci peut nuire à vos ambitions quant au BaaS ou réduire votre liste de four­nis­seurs po­ten­tiels. Par exemple, si le fait que les serveurs soient situés en UE est un critère important pour vous.