Pourquoi FTP plutôt que 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 la supply chain. Cependant, pour traiter les données, nous devons d’abord les importer. La plupart des applications web proposent des API web de style REST, mais Lokad propose FTPS et SFTP, ce qui peut sembler surprenant¹. Ce choix n’a pas été fait par hasard, mais dicté par les exigences de performance 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 antérieure, les forces en faveur du FTP sont toujours aussi fortes.

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 fraîches, généralement pas plus anciennes que la veille. La quantité totale de données impliquées, en supposant des fichiers texte plats non compressés (c’est-à-dire CSV), varie de 1 Go pour une entreprise de taille moyenne à 10 To pour une grande entreprise. En adoptant des transferts de données incrémentiels pour les tables plus volumineuses, le volume des transferts quotidiens varie généralement de 100 Mo à 10 Go.

L’entreprise cliente - ou son éditeur de logiciel, ou l’intégrateur de l’éditeur - doit réussir à pousser les données pertinentes vers Lokad. En effet, dans la plupart des situations, Lokad n’a jamais accès aux systèmes de production. Cela est raisonnable : pour des raisons de sécurité, les analyses tierces ne doivent pas avoir un accès direct aux systèmes de production. L’entreprise cliente doit rester maître, en tant que gardien, des données qui sortent de son système. De plus, cela lui permet de supprimer chaque bit de données personnelles, dont un tiers comme Lokad n’a même pas besoin de toute façon.

En théorie, REST peut être rendu performant de manière arbitraire. En pratique, ce n’est pas le cas. Avec REST, le transfert fiable de 100 Mo de données relationnelles fines, sur une base quotidienne, génère 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 le plus grand soin : la communication excessive et les tentatives de reprise. La communication excessive concerne le nombre d’appels sur le réseau. Les tentatives de reprise concernent les comportements nécessaires pour faire face aux pannes réseau transitoires. Les deux sont difficiles, voire extrêmement difficiles en pratique.

Dans l’espace de l’entreprise, la plupart des éditeurs de logiciels ne parviennent même pas à paginer correctement leurs propres API. Cette proposition selon laquelle les mêmes éditeurs, tout en déployant une intégration rapide et bâclée de Lokad, vont soudainement consacrer des talents d’ingénierie logicielle de premier ordre n’est pas raisonnable. Mon expérience chez Lokad indique que, au contraire, les travaux informatiques précipités sont ce que Lokad peut espérer de mieux. C’est bien. Il y a des tonnes de batailles à mener du point de vue informatique. Réaliste, l’intégration des données de Lokad ne peut pas être la seule bataille qui nécessite de mobiliser les forces d’élite.

En pratique, lorsque la pression est forte pour obtenir des performances décentes, les API web se transforment en transferts de fichiers plats via HTTP. Cette dégradation répond à l’aspect “bavardage” mentionné ci-dessus. Cependant, cela laisse encore ouverte la question des “tentatives de réessai”. Une fois que cette question est également résolue, félicitations, l’API a enfin réinventé un protocole de transfert de fichiers (FTP).

Cependant, cet FTP ad hoc est loin d’être aussi instrumenté que le véritable FTP. Le FTP est pris en charge par tous les principaux systèmes d’exploitation. Les deux bénéficient d’un important support d’outils open source. Les implémentations pertinentes sont utilisées en production depuis des décennies. Certes, il y a des particularités, ces protocoles ne sont peut-être plus “à la mode”, mais lorsqu’il s’agit de faire le travail en quelques heures sans impliquer des ingénieurs de renom, cela n’a même pas de comparaison.

C’est pourquoi Lokad a adopté le FTP pour prendre en charge les transferts de données entrants et sortants. De plus, une décennie d’exploitation a prouvé que ce choix était le bon. Même les entreprises informatiques externalisées à faible compétence et à faible coût réussissent à transférer rapidement et de manière fiable de grandes quantités de données relationnelles vers Lokad via FTP, ce qui ne s’est jamais produit, même une seule fois, pendant toutes les années où nous avons proposé une API web.