La piattaforma Lokad è orientata all’elaborazione di dati su scala di terabyte ed è destinata all’ottimizzazione predittiva della supply chain. Tuttavia, per elaborare i dati, è necessario prima importarli. La maggior parte delle app web presenta API web stilizzate come REST, ma Lokad presenta FTPS e SFTP, il che può sembrare sorprendente1. Questa scelta non è stata casuale, ma dettata dai requisiti delle prestazioni del trasferimento dei dati. Sebbene questa scelta sia stata fatta dieci anni fa basandosi sull’esperienza precedente, le ragioni a favore di FTP sono ancora forti come sempre.

Perché FTP invece di REST

Chiarifichiamo l’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, nel proprio account Lokad. Questi dati rappresentano il contenuto del suo ERP, MRP, WMS, POS, ecc. Nel tempo, le copie devono rimanere aggiornate, di solito non più vecchie di ieri. La quantità totale di dati coinvolti, assumendo file di testo piatti non compressi (cioè CSV), varia da 1 GB per un’azienda di medie dimensioni a 10 TB per un’azienda grande. Adottando trasferimenti di dati incrementali per le tabelle più grandi, il volume dei trasferimenti giornalieri varia tipicamente da 100 MB a 10 GB.

La società 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 delle situazioni, Lokad non ha mai accesso IT a nessun sistema di produzione. Questo è ragionevole: per motivi di sicurezza, le analisi di terze parti non dovrebbero avere accesso diretto ai sistemi di produzione. L’azienda cliente deve rimanere sotto controllo, come custode, dei dati che escono dal suo sistema. Inoltre, ciò consente loro di eliminare ogni singolo bit di dati personali, che una terza parte come Lokad non ha nemmeno bisogno.

In teoria, REST può essere reso arbitrariamente performante. Nella pratica, questo non è il caso. Con REST, il trasferimento affidabile di 100 MB di dati relazionali dettagliati, su base giornaliera, genera inevitabilmente enormi sovraccarichi delle prestazioni a meno che non sia coinvolto un team di ingegneria del software di prim’ordine. Due aspetti devono essere gestiti con la massima cura: la verbosità e i tentativi di ripetizione. La verbosità si riferisce al numero di chiamate sulla rete. I tentativi di ripetizione si riferiscono ai comportamenti necessari per far fronte a fallimenti di rete transitori. Entrambi sono difficili, soprattutto nella pratica.

Nel settore aziendale, la maggior parte dei fornitori di software non riesce nemmeno a gestire la paginazione correttamente per le proprie API. La proposta che gli stessi fornitori, mentre implementano un’integrazione veloce e approssimativa di Lokad, si dedichino improvvisamente a un talento di ingegneria del software di prim’ordine non è ragionevole. La mia esperienza presso Lokad indica che, al contrario, i lavori IT affrettati sono il massimo che Lokad può aspettarsi. Questo va bene. Ci sono tonnellate di battaglie da combattere dal punto di vista IT. Realisticamente, non ci si può aspettare che l’integrazione dei dati di Lokad sia l’unica battaglia che richiede l’intervento delle forze d’elite.

Nella pratica, quando si è sotto pressione per ottenere prestazioni decenti, le API web si trasformano in trasferimenti di file piatti tramite HTTP. Questa trasformazione affronta l’aspetto della “verbosità” menzionato in precedenza. Tuttavia, lascia ancora aperto l’aspetto dei “tentativi di ripetizione”. Una volta affrontato anche l’aspetto dei “tentativi di ripetizione”, congratulazioni, l’API ha finalmente reinventato un Protocollo di Trasferimento File (aka FTP).

Tuttavia, questo FTP ad hoc non è nemmeno lontanamente strumentato come quello reale. FTP è supportato da tutti i principali sistemi operativi. Entrambi hanno un enorme supporto di strumenti open source. Le implementazioni pertinenti sono state di livello di produzione per decenni. È vero, ci sono particolarità, quei protocolli potrebbero non essere più “alla moda”, ma quando si tratta di fare il lavoro entro poche ore senza coinvolgere ingegneri di fama mondiale, non c’è nemmeno paragone.

Ecco perché 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 era quella corretta. Anche le aziende IT esternalizzate a basso costo e bassa competenza riescono a trasferire grandi quantità di dati relazionali in modo rapido e affidabile a Lokad tramite FTP, cosa che non è mai successa, nemmeno una volta, durante tutti gli anni in cui abbiamo avuto una API web.


  1. In seguito, per motivi di concisione, FTP si riferisce sempre a “FTPS e SFTP”. Questi due protocolli sono piuttosto diversi, ma per questa discussione, queste differenze sono irrilevanti. Favorire un protocollo rispetto all’altro è principalmente una questione di allineamento con le pratiche IT preesistenti all’interno dell’azienda di interesse. ↩︎