Ho trovato molto interessante la lettura di questo post (qui la traduzione automatica). Mi da lo spunto di fare una riflessione su un problema, più ampio, che a mio parare stiamo affrontando in modo piuttosto acritico.

Nel post, che vi invito a leggere, l’autore testimonia il fatto che una larga fetta delle nuove generazioni di addetti al settore hanno un limite bem preciso nell’ambiente – software in questo caso – in cui sono abituati a muoversi, e -quindi – non hanno sufficiente coscienza (e, quindi, competenza) di come quell’ambiete funzioni: “Sebbene abbia sviluppato una straordinaria esperienza nelle migliori pratiche del cloud computing e nelle reti virtuali di nodi e servizi altamente disponibili, autoriparanti e con distribuzione automatica, sono rimasto per lo più all’oscuro dei dettagli di come funzionano effettivamente i sistemi host e i sistemi virtuali.”

Sistemi virtuali ed host che, in realtà, sono un ulteriore bozzolo costruito attorno all’oggetto del discorso, che è l’hardware vero e proprio.

Io vengo da una storia diametralmente opposta. Ho iniziato a scrivere software al liceo (classico) nella metà degli anni ’70,  quando l’unico oggetto programmabile alla mia portata era la Texas SR-52, che mi ha svezzato a scrivere codice efficiente per i suoi miseri 224 passi di programma. Intorno ai 18 anni ho iniziato l’attività sistemistica su un HP3000, ed uno dei primi prodotti del mio lavoro è stato un terminal emulator per sistemi CP/M, partendo dal reverse engineering dei protocolli usati dai terminali HP dell’epoca, e scrivendo il software in assembly Z80 per strette esigenze di velocità.  Va da se che per scrivere in assembly – dove interagisci direttamente con le varie componenti hardware – devi avere conoscenza e documentazione non solo delle architetture, ma del comportamento concreto di quello che devi andare a gestire. E quindi si lavorava con da una parte la tabella degli opcode, e dall’altra il datasheet del chip che dovevi controllare. Un approccio che, su vari livelli, ho mantenuto nel corso della mia carriere parallela di sviluppatore e di sistemista: sempre mantenere chiaro il quadro di assieme.

Nel corso degli anni lo sviluppo tecnologico ci ha messo nelle condizioni di lavorare meglio ed in modo più proficuo. L’incremento costante delle capacità computazionali dell’hardware e la creazioni di nuovi paradigmi di scrittura del software – come, giusto per esempio, la programmazione ad oggetti – ci hanno consentito di snellire il lavoro e di renderlo più efficiente. Cosa che è avvenuta stratificando le attività. Progressivamente abbiamo aggiunto strati a strati, a tutti i livelli, dal più basso al più alto.

Ovviamente ogni strato che ‘infiliamo’ nello stack del nostro sistema incrementa inevitabilmente la sua complessità. Se nell’immediato ci rende possibile semplificare il nostro lavoro, siamo così certi che l’uso indiscriminato – a lungo andare – ci porti sempre a benefici reali? Giusto un esempio. La containerizzazione, e tutto l’ecosistema collegato, ha delle applicazioni estremamente utili e funzionali. Ma che senso ha usarle anche quando il risultato può essere raggiunto mediante tecnologie meno evolute? Recentemente mi è capitato di intervenire su un sistema IOT su harware iMX8, sistema operativo debian, in cui l’applicazione girava appoggiandosi a servizi implementati in  contenitori Docker. Un approccio che ha come finalità solo quello di semplificare l’installazione e la configurazione del sistema, peraltro una tantum. Aggiunge inutilmente dei point of failure che potrebbero essere evitati, sottraendo nel contempo risorse computazionali ad un sistema dalle performance limitate.

Linux è nata su una filosofia, keep it simple stupid, che – in soldoni – ci dovrebbe spingere a progettare i sistemi utilizzando il livello di complessità più basso che ci consente di raggiungere il nostro scopo. Da un po’ di anni oramai ha preso piede un approccio diametralmente opposto, che mette in primo piano la sola comodità di realizzazione – che almeno influisce sui costi globali. O che sacrifica la solidità e l’affidabilità a finalità che poco hanno a che vedere con le ragioni tecniche – penso ad esempio al caso systemd.

L’uso indiscriminato di soluzioni inutilmente complesse, ci porta proprio alle conseguenze del post citato. Che mi ricorda molto l’atmosfera di uno dei capolavori di Asimov. In ‘Cronache della galassia’, la forza dell’Impero Galattico di Anacreon era basata sull’energia nucleare, ma con l’andare del tempo la sua classe dirigente aveva progressivamente perso la comprensione delle tecnologie usate. Al punto che la  sua ‘casta’ di tecnici non era oramai più in grado di andare oltre la manutenzione ordinaria: una debolezza che portò l’impero a dissolversi. D’altro Arthur C. Clarke, altro grande scrittore, affermava – a ragione – che “ogni tecnologia sufficientemente avanzata è indistinguibile dalla magia”.

Certo, fortunatamente non siamo ancora a questo punto. Ma credo che sia una possibilità che vada tenuta in debito conto.

Nella foto del titolo il particolare di una scheda PA_Risc HP9000 (Thomas Schanz / Wikimedia commons)