Gare au goulot d’étranglement des API dans la sauvegarde SaaS

François Lopitaux, chef de produit chez Odaseva partage son expertise sur le sujet.

C’est d’ailleurs un état de fait de la part de 65% des décideurs IT interrogés dans le cadre du rapport 2021 Evolution of Data Protection Cloud Strategies qui déclarent être partiellement ou entièrement responsables de la sauvegarde des données qu’ils exploitent dans les applications SaaS.

Mais, il reste encore un tiers des décideurs IT qui disent dépendre uniquement de leur fournisseur SaaS pour protéger les données de leur organisation. C’est encore beaucoup trop, car, même si les fournisseurs prennent grand soin de protéger leur infrastructure, ils ne sont pas responsables des données des clients. Et cela engendre un problème le jour où celles-ci sont accidentellement supprimées ou piratées. Le client est alors démuni.

Les sauvegardes SaaS dépendent d’une ressource limitée : les API

La sauvegarde des données SaaS est différente d’une protection traditionnelle in situ : celles-ci sont hébergées hors site, ce qui implique que le service informatique ne dispose pas d’un contrôle total. Pour accéder aux données, le système de sauvegarde SaaS doit passer par les API mises à disposition pour le fournisseur. Or, leur accès est souvent plafonné, et elles évoluent régulièrement. Les équipes informatiques doivent donc s’assurer qu’elles choisissent la bonne interface de programmation d’application, ainsi que définir des stratégies de gestion.

Des limites strictes pour les API Salesforce

La plupart des applications SaaS fonctionnent sur une base multi-locataires, ce qui signifie que plusieurs clients partagent les mêmes ressources, y compris les API. Par conséquent, il est courant que les fournisseurs SaaS, dont Salesforce, limitent le nombre d’appels d’API qu’un même client peut effectuer sur une période de 24 heures. L’idée étant de s’assurer que des ressources adéquates sont disponibles pour tous et que les clients ne consomment pas une quantité disproportionnée. Il en résulte que le service IT dispose d’une utilisation stricte de chaque API pour la sauvegarde. Il s’agit là d’une considération importante à prendre en compte, car les API ne sont pas exclusivement destinées à la sauvegarde – elles sont également utilisées pour interagir avec d’autres applications.

L’optimisation de la vitesse est aussi un aspect à surveiller, au moment de sélectionner les API pour sauvegarder ou restaurer les données. Par exemple, dans Salesforce, l’API REST peut déplacer 1 million d’enregistrements par heure, alors que l’API BULK peut en faire 10 millions. Et si le service informatique effectue des appels API parallèles pour multiplexer les données hors de Salesforce, REST ne peut pas dépasser plus de 10 millions d’enregistrements par heure, tandis que BULK peut quant à lui atteindre un maximum de 300 millions, selon la complexité et la taille de l’objet. Le choix de l’API peut ainsi faire une énorme différence pour les objectifs de points de reprise (RPO) d’une organisation.

Le problème de la dépendance à une seule API

Ce n’est pas parce qu’une API peut lire des données qu’elle est capable de les modifier, et cela engendre des implications importantes pour la restauration. Il se peut que certains objets puissent être restaurés avec un autre type d’API, mais il se peut aussi bien que certaines données ne puissent pas être restaurées en raison des limitations architecturales au sein de l’application SaaS elle-même.

Et ce n’est pas parce qu’il existe des limites à l’utilisation de chaque API qu’elles sont gravées dans le marbre. Les restrictions réelles de l’API sont basées sur l’accord de licence du client avec le fournisseur. Il est donc important de modéliser la quantité d’informations dont le service informatique pense avoir besoin pour utiliser chaque API. Il ne faut pas oublier non plus les besoins en API pour la restauration de grandes quantités de données.

Enfin, les API évoluent. Les systèmes de sauvegarde SaaS doivent s’adapter à ces changements, ce qui ajoute une complexité supplémentaire à un schéma déjà difficile de gestion et d’optimisation des API pour la protection des données.

Si les entreprises commencent à comprendre la nécessité de sauvegarder leurs données dans les services SaaS, elles ne sont pas forcément conscientes de la complexité de la mise en place d’un système de sauvegarde SaaS qui protège toutes les données de manière à respecter les RTO. L’examen minutieux de l’utilisation des API et le développement de stratégies pour les gérer doivent être une partie essentielle de la construction de toute solution de sauvegarde SaaS.

François Lopitaux est Chief Product Officer chez Odaseva, qui fournit une plateforme de gestion des données Grands Comptes pour Salesforce. Il apporte à Odaseva plus de 17 ans d’expérience dans la création de produits et services Cloud, du concept à plus de 400 millions de dollars de revenus. Avant de rejoindre Odaseva, M. Lopitaux a passé plus de dix ans chez Salesforce, où il a occupé plusieurs postes de gestion de produit, dont celui de vice-président en charge d’Einstein Analytics. Il est titulaire d’une maîtrise en informatique de l’ENSEIRB, Bordeaux, France.