La piattaforma Lokad è progettata per il processamento di dati su scala terabyte ed è destinata a un’ottimizzazione predittiva della supply chain optimization. Tuttavia, per poter elaborare i dati, è necessario importarli prima. La maggior parte delle applicazioni web presenta API web in stile REST, mentre Lokad utilizza FTPS e SFTP, che possono sembrare sorprendenti1. Questa scelta non è stata accidentale, ma dettata dai requisiti prestazionali dei trasferimenti dati. Seppure questa scelta sia stata fatta un decennio fa basandosi su esperienze precedenti, le forze a favore di FTP sono tuttora altrettanto forti.

Perché FTP invece di REST

Chiarifichiamo il caso d’uso di Lokad. Un’azienda cliente tipica deve trasferire la copia integrale di 10 a 100 tabelle di database, da 5 a 500 campi per tabella, sul suo account Lokad. Questi dati rappresentano il contenuto del suo ERP, MRP, WMS, POS, ecc. Col tempo, le copie devono rimanere aggiornate, tipicamente non più vecchie della data di ieri. La quantità totale dei dati coinvolti, assumendo file di testo piano non compressi (cioè CSV), varia da 1 GB per un’azienda media a 10 TB per una grande azienda. Adottando trasferimenti incrementali per le tabelle più grandi, il volume dei trasferimenti giornalieri varia tipicamente da 100 MB a 10 GB.

L’ azienda cliente - o il suo fornitore di software, o l’integratore del fornitore - deve riuscire a inviare i dati rilevanti a Lokad. Infatti, nella maggior parte dei casi, Lokad non ottiene mai accesso IT a nessun sistema di produzione. Ciò è ragionevole: per motivi di sicurezza, le analisi condotte da terzi non dovrebbero avere accesso diretto ai sistemi di produzione. L’azienda cliente deve rimanere in controllo, in qualità di guardiano, dei dati che escono dal suo sistema. Inoltre, questo le consente di eliminare ogni singolo bit di dato personale, di cui un soggetto terzo come Lokad non ha nemmeno bisogno.

In teoria, il REST può essere reso arbitrariamente performante. In pratica, tuttavia, non è così. Con il REST, trasferire quotidianamente 100 MB di dati relazionali a granualità fine genera invariabilmente enormi sovraccarichi prestazionali, a meno che non sia coinvolto un team di ingegneria software di prim’ordine. Due aspetti devono essere gestiti con la massima cura: l’eccessiva comunicazione e i ritentativi. L’eccessiva comunicazione riguarda il numero di chiamate in rete. I ritentativi riguardano i comportamenti necessari a fronteggiare i fallimenti transitori della rete. Entrambi sono difficili, e in pratica estremamente così.

Nel settore enterprise, la maggior parte dei fornitori di software non riesce nemmeno a gestire correttamente il paging per le proprie API. L’ipotesi che gli stessi fornitori, durante una rapida e approssimativa integrazione di Lokad, improvvisamente dedichino talenti di ingegneria software di prim’ordine non è ragionevole. La mia esperienza in Lokad indica che, al contrario, lavori IT condotti in fretta sono il massimo che ci si possa aspettare. Va bene così. Ci sono innumerevoli battaglie da combattere in ambito IT. In realtà, l’integrazione dei dati in Lokad non può essere quella battaglia che richiede il dispiegamento delle forze d’élite.

In pratica, quando si è sotto pressione per ottenere prestazioni decenti, le API web si riducono a trasferimenti di file flat tramite HTTP. Questa semplificazione affronta l’aspetto dell’‘eccessiva comunicazione’ menzionato sopra. Tuttavia, lascia ancora aperto l’aspetto dei ‘ritentativi’. Una volta affrontato anche quest’ultimo, congratulazioni, l’API ha finalmente reinventato un File Transfer Protocol (alias FTP).

Tuttavia, questo FTP ad hoc è ben lontano dall’essere così ben strumentato come il vero protocollo. FTP è supportato da tutti i principali sistemi operativi. Entrambi dispongono di un ampio supporto di strumenti open source. Le implementazioni pertinenti sono da decenni di livello produttivo. È vero, ci sono stranezze, e quei protocolli potrebbero non essere più “di moda”, ma quando si tratta di portare a termine il lavoro in poche ore senza coinvolgere ingegneri rockstar, non paragonano affatto.

Per questo motivo, Lokad ha adottato FTP per supportare sia i trasferimenti di dati in entrata che in uscita. Inoltre, un decennio di operazioni ha dimostrato che questa scelta è stata quella giusta. Persino aziende IT esternalizzate, a basso costo e con competenze limitate, riescono a trasferire grandi quantità di dati relazionali a Lokad in modo rapido e affidabile tramite FTP, cosa che non è mai accaduta, nemmeno una volta, durante tutti gli anni in cui abbiamo utilizzato un’API web.


  1. Di seguito, per concisione, FTP si riferisce sempre a “FTPS and SFTP”. Questi due protocolli sono abbastanza diversi, ma ai fini di questa discussione tali differenze sono irrilevanti. Favorire un protocollo rispetto all’altro è per lo più una questione di allineamento con le pratiche IT preesistenti all’interno dell’azienda in questione. ↩︎