L'eleganza della soluzione

Quando si lavora nell'IT, è molto facile concentrarsi su soluzioni grandi e complesse. Sembra che sia proprio qui che debbano risiedere le buone soluzioni – grandi soluzioni, molto software, tutti i gadget più recenti. Quello che facciamo è entusiasmante ed è molto facile lasciarsi trascinare dallo slancio. È divertente affrontare progetti grandi e impegnativi. Sentire ciò che fanno gli altri professionisti dell'IT, come altre aziende risolvono le sfide e parlare con fornitori che hanno grandi sistemi da venderci contribuisce tutto all'entusiasmo, ed è molto facile perdere il senso dell'ambito e dell'obiettivo; ed è così comune vedere soluzioni grandi ed esagerate a problemi semplici che sembra che questo debba essere semplicemente il modo in cui funziona l'IT.

Ma non è necessario che sia così. La complessità è nemica sia dell'affidabilità sia della sicurezza. Le soluzioni inutilmente complesse aumentano i costi sia di acquisizione sia di implementazione, oltre che di manutenzione, pur essendo generalmente più lente, più fragili e dotate di un'ampia superficie di attacco più difficile da comprendere e proteggere. Le soluzioni semplici, o più propriamente eleganti, sono l'approccio migliore. Questo non significa che tutti i progetti saranno semplici, niente affatto. I progetti complessi sono spesso necessari. L'IT non è certo un campo che difetti di complessità. Anzi, si crede spesso che lo sviluppo software possa essere la più complessa di tutte le imprese umane, almeno tra quelle intraprese su qualsiasi scala. Un'installazione IT tipica comprende milioni di righe di codice, centinaia o migliaia di protocolli, un gran numero di sistemi interconnessi, livelli di configurazioni software uniche, più impostazioni di quante qualsiasi team potrebbe mai conoscere, e solo a quel punto aggiungiamo la complessità di centinaia, migliaia o centinaia di migliaia di esseri umani imprevedibili e irrazionali che cercano di usare questi sistemi, ciascuno a modo proprio. L'IT è, senza alcun dubbio, complesso.

Ciò che è importante è riconoscere che l'IT è complesso, che questo non può essere evitato completamente, ma concentrarsi sul progettare e ingegnerizzare soluzioni che siano il più semplici, il più armoniose… il più eleganti possibile. Questa idea di progettazione proviene, almeno a mio avviso, dall'ingegneria del software, dove il codice complesso è visto come un errore e il codice semplice e bello, facile da leggere e da comprendere, è considerato di successo. Uno dei più alti riconoscimenti che si possano conferire a un'ingegnere del software è che il suo codice venga definito elegante. Quanto è appropriato che venga attribuita a Blaise Pascal, dal quale prese il nome uno dei linguaggi di programmazione più diffusi degli anni '70 e '80, questa celebre citazione (tradotta malamente dal francese): “Mi dispiace di averle dovuto scrivere una lettera così lunga, ma non ho avuto il tempo di scrivergliene una breve.”

Spesso è molto più facile progettare soluzioni complesse e contorte che non determinare quale approccio semplice potrebbe bastare. Che si abbia fretta o non si sappia da dove cominciare un'indagine, l'eleganza è sempre una sfida. Lo slancio del settore tende a promuovere il percorso più difficile. È nell'interesse dei fornitori vendere più apparecchiature non solo per concludere la vendita iniziale, ma perché sanno che con più apparecchiature arrivano più dollari di assistenza, e se viene venduta abbastanza nuova apparecchiatura complessa le esigenze di assistenza smettono di crescere in modo lineare e iniziano a crescere in modo geometrico, poiché ulteriore assistenza è necessaria non solo per l'apparecchiatura o il software in sé, ma anche per la configurazione e il supporto delle interazioni tra sistemi o per ulteriori personalizzazioni. Le influenze finanziarie dietro la complessità sono notevoli, e non si fermano ai fornitori. I professionisti dell'IT ottengono molta sicurezza del posto di lavoro, o l'illusione di essa, gestendo grandi insiemi di hardware e software difficili da trasferire senza intoppi a un altro professionista dell'IT.

Spesso la complessità è così data per scontata, così attesa, che il processo di selezione di una soluzione comincia con grande complessità come conclusione già acquisita, senza alcuna considerazione per la possibilità che una soluzione meno complessa possa bastare, o persino essere superiore al di là della questione della complessità e del costo stessi. La complessità è talvolta persino del tutto legata a determinati concetti a un punto tale che mi sono effettivamente trovato di fronte all'incredulità di fronte all'idea che una soluzione semplice possa superare, per prezzo, prestazioni e affidabilità, una soluzione complessa.

La retorica è facile, ma qual è un esempio del mondo reale? I migliori esempi che vedo oggi sono per lo più legati alla virtualizzazione, sia che si tratti dello storage, di un livello di gestione cloud, del software o semplicemente della virtualizzazione in sé. Vedo molto spesso che una conversazione che riguarda la sola virtualizzazione evoca all'istante, per qualcuno, la connotazione di richiedere storage a blocchi condiviso in rete, costoso software di gestione della virtualizzazione, molti nodi di virtualizzazione ridondanti e complesso software di alta disponibilità – nessuno dei quali è intrinseco alla virtualizzazione, e la maggior parte dei quali raramente ha lo scopo di sostenere, o anche solo è davvero nell'interesse dell'azienda per cui verranno implementati. Invece di partire dai requisiti aziendali, questi concetti scaturiscono prevalentemente da preconcetti tecnologici. È semplice additare la complessità e dare l'impressione di star risolvendo un problema – la complessità crea un senso di conforto. Riducete molte argomentazioni all'essenziale e sentirete “Come può non funzionare, è complesso?” La complessità fornisce un'illusione di completezza, o di aver risolto un problema, ma questo può comunemente nascondere il fatto che una soluzione potrebbe in realtà non essere completa o persino funzionale, mentre il grado di complessità rende difficile accorgersene. La nostra mente, allora, non accetterà facilmente che un approccio più semplice sia più completo e risolva un problema laddove uno complesso non lo fa, perché ci appare talmente controintuitivo.

Un ottimo esempio di questo è che ricorriamo a discutere di ridondanza anziché di affidabilità. L'affidabilità è difficile da misurare, la ridondanza è semplice da quantificare. Un mattone è altamente affidabile, anche quando è uno solo. Non occorre ridondanza perché un mattone sia stabile e robusto. Il suo progetto è semplice. Si potrebbe realizzare una struttura portante con molti bastoncini ridondanti che non sarebbe lontanamente affidabile quanto un singolo mattone. Se si parla in termini di affidabilità – la probabilità che la struttura non ceda – è chiaro che il mattone è una scelta superiore rispetto a diversi bastoncini. Ma se si dice “però non c'è ridondanza, il mattone potrebbe cedere e non c'è nulla a prenderne il posto” si suona ridicoli. Eppure, quando si parla di computer e sistemi informatici, troviamo sistemi così complessi che raramente le persone si accorgono di quando hanno un mattone o un bastoncino e così, poiché non riescono a determinare l'affidabilità che conta, si concentrano sulla ridondanza facile da quantificare, che non conta. L'intero sistema è troppo complesso, ma cercare la soluzione semplice, quella che affronta direttamente il nocciolo del problema da risolvere, può ridurre la complessità e fornirci alla fine una risposta di gran lunga migliore.

Lo si può vedere anche nel RAID. Il RAID mirror è semplice: un solo disco o insieme di dischi è una copia esatta di un altro insieme. È semplicissimo. Il RAID a parità è complesso, con calcoli su uno stripe variabile attraverso molti dispositivi che devono essere codificati al momento della scrittura e decodificati qualora un dispositivo si guasti. Il RAID mirror è privo di questa complessità e risolve il problema dell'affidabilità del disco mediante semplici ed eleganti operazioni di copia che sono altamente affidabili e molto ben comprese. Il RAID a parità è inutilmente complesso, il che lo rende fragile. Eppure, così facendo e minando la propria capacità di risolvere il problema per cui è stato concepito, esso allo stesso tempo appare anche più affidabile, sulla base di nessun fattore se non la propria complessità. La mente umana salta immediatamente a “è complesso, quindi è più avanzato, quindi è più affidabile”, ma nessuna delle due progressioni è logica. La complessità non implica che sia più avanzato, ed essere avanzato non implica che sia affidabile, ma la mente umana stessa è complessa e facilmente tratta in inganno.

Non esiste una risposta semplice per trovare la semplicità. Sapere che la complessità è negativa per sua natura ma a volte inevitabile ci insegna a essere attenti, tuttavia non ci insegna quando sospettare un eccesso di complessità. Dobbiamo essere vigili, cercando sempre di stabilire se esista una risposta più elegante e non accettare la complessità come risposta corretta semplicemente perché è complessa. Dobbiamo mettere in discussione le soluzioni proposte e mettere in discussione noi stessi. “Questa soluzione è davvero semplice quanto dovrebbe essere?” “Questa complessità è necessaria?” “Questo richiede la complessità che avevo dato per scontata?”

Nella maggior parte delle raccomandazioni di progettazione di sistemi che fornisco, il primo passo di valutazione tecnica che normalmente compio, dopo il passo di indagare sull'esigenza aziendale da risolvere, è mettere in discussione la complessità. Se la complessità non può essere difesa, è probabilmente inutile e attivamente controproducente rispetto allo scopo per cui è stata scelta.

“È davvero necessario suddividere quei dischi in molti array separati? Se sì, qual è la giustificazione tecnica per farlo?”

“Lo storage condiviso è davvero necessario per il compito per cui lo si propone?”

“L'azienda giustifica davvero l'uso di tecnologie distribuite di alta disponibilità?”

“Perché stiamo sostituendo un sistema semplice che ieri era adeguato con un sistema drasticamente più complesso domani? Cosa è cambiato che rende un miglioramento sostanziale, pur rimanendo semplice, non più che sufficiente ma che richiede ordini di grandezza in più di complessità e di spesa che prima non erano giustificati?”

Questi sono solo esempi comuni, la complessità esiste in ogni aspetto del nostro settore. Cercate la semplicità. Aspirate all'eleganza. Non accettate la complessità senza vagliarla rigorosamente. Sottoponetela alla proverbiale prova del fuoco. Non permettete alla complessità di insinuarsi dove non è giustificata. Non sbagliate per eccesso di complessità – nel dubbio, fallite in modo semplice. Semplificare eccessivamente una soluzione di solito si traduce in un guasto di lieve entità, mentre renderla eccessivamente complessa consente un grado di guasto ben maggiore. La scommessa più sicura è quella con la soluzione più semplice. E se si sceglie una soluzione semplice e la si dimostra inadeguata, è molto più facile aggiungere complessità che rimuoverla.