Quanto potere di calcolo serve per gestire un parco di predatori preistorici senza che finiscano tutti a cena con gli ospiti? Se la risposta è ‘un cluster di supercomputer che costa quanto il PIL di una piccola nazione’, allora siete sulla strada giusta.
Recentemente è spuntato fuori un approfondimento tecnico che fa impazzire chiunque abbia mai passato una notte in bianco a debuggare un kernel o a configurare un network che non dovrebbe esistere. L’autore scava nel ventre tecnologico di Jurassic Park, rivelando che il sistema non era solo un ammasso di effetti speciali, ma si basava su qualcosa di estremamente reale: la CM-5, la ‘Connection Machine’.
Se leggete bene le linee di dialogo di Dennis Nedry — il nostro amato sysadmin traditore — capite che non sta solo delirando per il troppo caffè. Quando si lamenta di dover far comunicare 8 Connection Machines e gestire 2 milioni di righe di codice, non sta facendo hype da marketing. Sta descrivendo l’incubo di chiunque debba gestire un’infrastruttura distribuita senza documentazione aggiornata e con un budget che sembra deciso da un produttore di Hollywood.
La CM-5 era una macchina reale, un’architettura massivamente parallela che oggi ci farebbe sognare per addestrare modelli di AI, ma che all’epoca rappresentava l’apice del computing scientifico. Vedere questa tecnologia integrata in un parco a tema ci ricorda che, mentre oggi ci perdiamo in discussioni su quale framework JavaScript usare per un sito di ricette, i veri problemi (quelli che portano alla fuga di un T-Rex) richiedono una gestione della complessità che farebbe tremare i polsi a un DevOps senior.
C’è un lato quasi poetico, e tragico, in tutto questo. Il sistema era così avanzato, così automatizzato e così ‘chiuso’ nel suo ecosistema proprietario, che bastava un singolo punto di fallimento — o un insider con un grudge accumulato — per far saltare tutto. È lo stesso rischio che corriamo oggi quando affidiamo la nostra intera esistenza a ecosistemi che non controlliamo, dove un errore di configurazione o un sabotaggio logico possono rendere inutile l’intera infrastruttura.
In un mondo che cerca sempre di semplificare tutto con il cloud e l’automazia spinta, l’analisi di questi sistemi ci ricorda che la tecnologia, per quanto incredibile, resta sempre fragile. E che, alla fine, nessuna automazione potrà mai sostituire la necessità di un sistema ben progettato, trasparente e, soprattutto, che non dipenda dall’umore di un programmatore non pagato il giusto.