Pourquoi FTP au lieu de REST

Joannes Vermorel

La plateforme Lokad est conçue pour le traitement de données à l’échelle des téraoctets et destinée à l’optimisation prédictive de l’optimization de la supply chain. Cependant, afin de traiter les données, nous devons d’abord les importer. La plupart des applications web proposent des API web de style REST, pourtant Lokad propose FTPS et SFTP, ce qui peut sembler surprenant¹. Ce choix n’est pas accidentel mais dicté par des exigences de performance lors du transfert de données. Bien que ce choix ait été fait il y a une décennie, sur la base d’une expérience préalable, les arguments en faveur du FTP restent aussi convaincants qu’auparavant.

Clarifions le cas d’utilisation de Lokad. Une entreprise cliente typique doit transférer la copie intégrale de 10 à 100 tables de base de données, de 5 à 500 champs par table, vers son compte Lokad. Ces données représentent le contenu de son ERP, MRP, WMS, POS, etc. Au fil du temps, les copies doivent rester à jour, généralement pas plus anciennes que le jour d’hier. La quantité totale de données impliquées, en supposant des fichiers texte plats non compressés (c’est-à-dire CSV), varie de 1 GB pour une entreprise de taille moyenne à 10 TB pour une grande entreprise. En adoptant des transferts de données incrémentaux pour les tables les plus volumineuses, le volume des transferts quotidiens varie généralement de 100 MB à 10 GB.

L’entreprise cliente - ou son éditeur de logiciels, ou l’intégrateur de l’éditeur - doit réussir à envoyer les données pertinentes vers Lokad. En effet, dans la plupart des situations, Lokad n’obtient jamais d’accès IT à un système de production. Cela est raisonnable : pour des raisons de sécurité, les analyses tierces ne devraient pas avoir un accès direct aux systèmes de production. L’entreprise cliente doit rester en contrôle, en tant que gardien, des données qui sortent de son système. En prime, cela leur permet d’éliminer chaque parcelle de données personnelles, dont un tiers comme Lokad n’a d’ailleurs pas besoin.

En théorie, le REST peut être rendu arbitrairement performant. En pratique, ce n’est pas le cas. Avec le REST, transférer de manière fiable 100 MB de données relationnelles détaillées, sur une base quotidienne, engendre invariablement d’énormes surcharges de performance, à moins qu’une équipe d’ingénierie logicielle de premier ordre ne soit impliquée. Deux aspects doivent être traités avec un soin extrême : la verbosité et les réessais. La verbosité se rapporte au nombre d’appels sur le réseau. Les réessais concernent les comportements nécessaires pour faire face aux défaillances transitoires du réseau. Les deux sont difficiles, extrêmement, en pratique.

Dans le secteur de l’entreprise, la plupart des éditeurs de logiciels n’arrivent même pas à bien gérer la pagination pour leurs propres API. L’hypothèse selon laquelle ces mêmes éditeurs, tout en déployant une intégration rapide et approximative de Lokad, vont soudainement consacrer des talents d’ingénierie logicielle de premier ordre n’est pas raisonnable. Mon expérience chez Lokad indique, au contraire, que les tâches informatiques réalisées à la hâte sont le mieux que Lokad puisse espérer. Cela va. Il y a d’innombrables batailles à mener dans le domaine IT. Réalistiquement, l’intégration des données de Lokad ne peut être considérée comme la seule bataille nécessitant de faire appel aux forces d’élite.

En pratique, lorsqu’on est sous pression pour obtenir des performances décentes, les API web se transforment en transferts de fichiers plats sur HTTP. Cette dévolution permet de résoudre le problème de la verbosité évoquée ci-dessus. Cependant, elle laisse encore la question des réessais en suspens. Une fois que l’aspect des réessais est également pris en compte, félicitations, l’API a enfin réinventé un protocole de transfert de fichiers (alias FTP).

Cependant, ce FTP improvisé est loin d’être aussi bien instrumenté que le véritable. Le FTP est pris en charge par tous les principaux systèmes d’exploitation. Les deux bénéficient d’un support massif d’outils open source. Les implémentations concernées sont de niveau production depuis des décennies. Certes, il existe des particularités, ces protocoles ne sont peut-être plus “fashionable” aujourd’hui, mais lorsqu’il s’agit de mener à bien la tâche en quelques heures sans impliquer des ingénieurs rockstar, rien ne peut s’y comparer.

C’est pourquoi Lokad a adopté le FTP pour supporter à la fois les transferts de données entrants et sortants. De plus, une décennie d’opérations a prouvé que ce choix était le bon. Même des entreprises IT externalisées, à faibles compétences et à bas coût, réussissent à transférer de grandes quantités de données relationnelles rapidement et de manière fiable vers Lokad via FTP, ce qui n’est jamais arrivé, pas une seule fois, durant toutes les années pendant lesquelles nous avons proposé une API web.