Sulla complessità accidentale dei sistemi di supply chain

Joannes Vermorel

L’hardware di calcolo moderno è estremamente capace. Uno smartphone modesto offre miliardi di FLOPS (operazioni in virgola mobile al secondo) mentre memorizza centinaia di gigabyte di dati. Un singolo smartphone potrebbe tecnicamente gestire un’allocazione predittiva delle scorte per una rete di vendita al dettaglio molto ampia. I dati storici richiederebbero una rappresentazione adeguata¹ e sul lato dell’elaborazione dei dati, sarebbe necessario utilizzare tecniche più snelle come la programmazione differenziabile. Pertanto, i sistemi di supply chain ad alte prestazioni dovrebbero essere una certezza. Sicuramente, le aziende possono permettersi qualcosa di meglio di uno smartphone per gestire ed ottimizzare le loro supply chain. Tuttavia, un’osservazione casuale dei sistemi di supply chain dei nostri clienti presso Lokad indica esattamente il contrario: questi sistemi sono quasi sempre lenti e spesso torturanti.

I leader del software di supply chain odierno (ERP, WMS, MRP, ecc.) hanno difficoltà a sostenere anche una richiesta al secondo sul loro backend API. Da Lokad, siamo dolorosamente ricordati di tali prestazioni orribili quotidianamente, poiché siamo in prima linea nel processo di recupero dei dati. Per una dozzina di clienti circa, il recupero iniziale dei dati richiedeva quasi un mese². La lentezza delle varie API rappresenta il 99,9% del problema. I sistemi capaci di sostenere 1MB/secondo per l’estrazione dei dati sono pochi e distanti tra loro. I sistemi che non ci costringono a estrarre inutilmente gli stessi dati più volte - per raggiungere le parti più recenti - sono ancora più rari. Tali sistemi di solito dispongono di oltre 100 risorse di calcolo in più rispetto a quelle di 2 decenni fa, eppure non sono fondamentalmente più veloci³ né fanno le cose in modo radicalmente migliore. Alcuni dei fornitori più progressisti che sfruttano il calcolo in memoria richiedono diversi terabyte di RAM per gestire le reti di vendita al dettaglio, che è una quantità di RAM sorprendentemente grande⁴ considerando ciò che viene fatto con tali risorse.

Questa “complessità accidentale” di molti (la maggior parte?) dei sistemi di supply chain può essere ricondotta a due cause principali: in primo luogo, aspettative errate sul progresso dell’hardware di calcolo stesso, in secondo luogo, una mancanza di attenzione per il design interno della soluzione.

Sul progresso dell’hardware di calcolo, fino a un decennio fa, non c’era una singola (grande) azienda in cui la prima legge di Moore non fosse stata presentata decine di volte (di solito in modo errato). C’era la sensazione che i computer stessero diventando ridicolmente più veloci tutto il tempo. Purtroppo, questo è in gran parte cessato di essere banalmente vero dagli inizi degli anni 2000. Questa prospettiva errata di progresso indefinito ha portato molte aziende di software, ben oltre il mondo della supply chain, a commettere errori massicci. Molte delle difficoltà associate a Windows Vista (rilasciato nel 2006) potevano essere ricondotte alle aspettative originali - risalenti al 2001 quando è stato rilasciato Windows XP - degli ingegneri di Microsoft che le CPU sarebbero state cronometrate a 6Ghz entro il 2006. Stiamo avvicinandoci alla fine del 2020 e le CPU per il gaming di fascia alta stanno appena raggiungendo i 5Ghz. L’hardware di calcolo non ha mai smesso di progredire; tuttavia, ha semplicemente smesso di progredire in modo banale, almeno per quanto riguarda le aziende di software.

Negli anni ‘80 e ‘90, non appena un software funzionava, anche se era un po’ lento al momento del rilascio, era scontato che l’anno successivo la sua velocità sarebbe stata decente e l’anno dopo eccellente. Aziende di software aggressive come Microsoft hanno giocato molto bene questa carta: i loro ingegneri ricevevano (e ancora ricevono) l’hardware di calcolo migliore che il denaro potesse comprare e spingevano sistematicamente le prestazioni del software al limite di ciò che rimaneva accettabile, sapendo che l’hardware avrebbe essenzialmente risolto il problema delle prestazioni, più o meno entro un anno o due. Dopo il disastro di Vista, i team di ingegneria di Microsoft si sono resi conto dell’entità del problema e hanno cambiato il loro approccio - Windows 7 è stata un’importante miglioramento. Tuttavia, ci sono voluti dieci anni perché Windows si riprendesse veramente sul fronte delle prestazioni. Oggi, la prospettiva è quasi l’esatto opposto: i migliori team di Microsoft non si basano più sull’hardware futuro, ma si concentrano quasi esclusivamente sul fornire prestazioni superiori immediate tramite software superiore⁵.

Tuttavia, il mondo del software aziendale si è rivelato molto più lento nel notare il problema e ha continuato a sviluppare software durante gli anni 2010 come se l’hardware di calcolo futuro fosse sul punto di risolvere tutti i loro problemi, come era successo molte volte in passato. Sfortunatamente, per la maggior parte dei fornitori di software aziendale, sebbene l’hardware di calcolo stia ancora progredendo, un decennio fa ha smesso di progredire in modo banale⁶, dove il fornitore può semplicemente aspettare che le prestazioni si verifichino. Il software tende ad accumulare spazzatura nel tempo (più funzionalità, più opzioni, più schermate, ecc.). Pertanto, la tendenza naturale del software complesso è di rallentare nel tempo, non di migliorare, a meno che non ci sia un intenso sforzo dedicato su questo fronte.

Purtroppo, dal punto di vista delle vendite, le prestazioni sono per lo più un non-problema. Le demo vengono fatte con account di prova che includono solo una piccolissima frazione del carico di lavoro dei dati che il sistema affronterebbe in produzione. Inoltre, gli schermi di interesse per la alta dirigenza ricevono una quantità sproporzionata di attenzione rispetto a quelli destinati ai dipendenti. Eppure, sono proprio questi ultimi schermi che verranno utilizzati migliaia di volte al giorno e quindi quelli che meritano la massima attenzione. Sospetto che le API offrano spesso prestazioni terribili perché pochi acquirenti indagano se le API stanno effettivamente offrendo prestazioni allineate con il loro scopo previsto. I fornitori di software lo sanno e allineano i loro investimenti ingegneristici di conseguenza.

Questo mi porta al secondo aspetto del problema delle prestazioni: la mancanza di attenzione per il design interno della soluzione. Attualmente, sono necessarie decisioni strategiche di design del software per sfruttare la maggior parte dei miglioramenti hardware in corso. Tuttavia, una decisione di design è un’arma a doppio taglio: dà potere ma limita anche. È necessario un forte leadership per impegnarsi sia dal lato aziendale che da quello tecnico in una decisione di design. L’incertezza è più facile, ma, come illustrato dalla stragrande maggioranza del software aziendale, le prestazioni (e l’esperienza utente in generale) ne risentono notevolmente.

Una trappola del software moderno (non solo quello aziendale) è l’eccesso di strati. I dati vengono copiati, instradati, raggruppati, sincronizzati… attraverso decine di strati interni all’interno del software. Di conseguenza, la maggior parte delle risorse di calcolo viene sprecata nel gestire la “plumbing interna”, che di per sé non offre alcun valore aggiunto. In termini di design, la soluzione è sia semplice da concepire che difficile da eseguire: è necessario fare un uso parsimonioso dei componenti di terze parti, specialmente quelli che comportano uno strato di qualche tipo⁷. Dal punto di vista dei fornitori di software, aggiungere un altro strato è il modo più rapido per aggiungere più “funzionalità cool” al prodotto, senza preoccuparsi della sovrabbondanza.

Alla Lokad, abbiamo optato per una stack estensivamente integrata progettando l’intera piattaforma attorno ad un core di compilazione. Sul lato negativo, perdiamo la possibilità di collegare facilmente qualsiasi progetto open source casuale al nostro design. Le integrazioni rimangono possibili ma di solito richiedono modifiche più profonde nel compilatore stesso. Sul lato positivo, otteniamo prestazioni “bare metal” che di solito sono considerate impensabili per quanto riguarda il software aziendale. Nel complesso, considerando che i componenti open source stanno invecchiando male, questo approccio si è dimostrato particolarmente efficace nell’ultimo decennio⁸.

La multi-tenancy mutualizzata è un’altra scelta di design che influenza radicalmente le prestazioni, almeno dal punto di vista del “rapporto qualità-prezzo”. La maggior parte del software aziendale - incluso il software di supply chain - ha requisiti fortemente intermittenti di risorse di calcolo. Ad esempio, all’estremo opposto dello spettro, abbiamo la previsione ricetta numerica, che viene eseguita solo una volta al giorno (o giù di lì) ma deve elaborare l’intero storico dei dati ogni volta. Avere un insieme statico di risorse di calcolo⁹ dedicate a un cliente è altamente inefficiente.

Ancora una volta, alla Lokad, abbiamo optato per un’infrastruttura completamente mutualizzata. Questo approccio riduce i nostri costi operativi cloud pur offrendo prestazioni che altrimenti non sarebbero economicamente sostenibili (i costi cloud supererebbero i benefici della supply chain). Al fine di garantire una gestione complessiva ottimale di tutti i carichi di lavoro, abbiamo progettato un alto grado di “prevedibilità” per il nostro consumo di risorse di calcolo. Il DSL (linguaggio di programmazione specifico del dominio) di Lokad, chiamato Envision, è stato progettato per supportare questo obiettivo. Ecco perché intere classi di costrutti di programmazione - come i loop arbitrari - non esistono in Envision: tali costrutti non sono compatibili con i requisiti di “alta prevedibilità” che comporta l’elaborazione dei dati della supply chain.

In conclusione, non aspettarti che un sistema di supply chain obeso diventi efficiente in breve tempo se non lo è già. Mentre l’hardware di calcolo sta ancora progredendo, è già abbastanza veloce. Se il sistema è lento, molto probabilmente è perché si contrappone all’hardware sottostante, non perché l’hardware è carente. Risolvere il problema è possibile, ma è principalmente una questione di design. Purtroppo, il design del software di base è una delle cose che tende ad essere quasi impossibile da correggere nel software aziendale dopo la fase di progettazione del prodotto. Tuttavia, è possibile recuperare, come dimostrato da Microsoft, ma non tutte le aziende (sia fornitori che clienti) possono permettersi il decennio che ci vuole per farlo.