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.