Scegliere le versioni del software da distribuire

Qualcosa di cui vedo discutere molto spesso negli ambienti IT è “quale versione del software dovrei installare”. Questo potrebbe riguardare un database, un’applicazione, un firmware o, probabilmente ancora più spesso, i sistemi operativi e, con l’imminente fine del supporto per Windows XP, l’argomento ha raggiunto toni febbrili.

Vi sono di fatto due fronti in questa discussione. Un fronte ritiene che debba essere sempre utilizzato il software più recente e, presumibilmente, migliore. L’altro ritiene che il software debba maturare e adotta un approccio del tipo “aspetta e osserva”, o considera addirittura ciascuna versione come un prodotto diverso e non come un continuum di sviluppo.

Entrambi gli approcci hanno i loro meriti e nessuno dei due dovrebbe esistere completamente senza l’altro. Aggiornare il software ciecamente e a casaccio non è saggio, e nemmeno evitare patch e aggiornamenti senza motivo lo è. È importante tenere a mente un’attenta considerazione dei fattori e una certa empatia verso il processo di sviluppo del software quando si prendono queste decisioni.

Innanzitutto, vi sono due scenari completamente diversi da considerare. Uno è l’aggiornamento di software attuale ed esistente. Il presupposto è che lo stato attuale delle cose sia “funzionante”, con la possibilità accettata che “funzionante” possa includere una vulnerabilità di sicurezza scoperta e che richiede un aggiornamento per essere chiusa. L’altro scenario è una nuova distribuzione in cui non c’è nulla di attuale e si parte da zero.

Iniziamo dal secondo caso, poiché è molto più facile fornire indicazioni in merito.

Nel caso di nuove distribuzioni software (o di nuovi sistemi operativi), utilizzare sempre la versione attuale e più recente del software, a meno che non vi sia una limitazione tecnologica chiaramente nota che lo impedisca – come bug noti o incompatibilità software.

Il software non è come gli altri tipi di prodotti, soprattutto non nel mondo odierno dei rilasci di patch e degli aggiornamenti online. Presumo che la mentalità secondo cui le vecchie versioni del software potrebbero essere preferibili a quelle attuali derivi da una combinazione di prodotti fisici (orologi, automobili, stoviglie, mobili, vino), in cui un anno o un modello specifico potrebbe essere superiore a un modello più recente per vari motivi, e di modalità legacy di distribuzione del software, in cui i prodotti software finiti venivano semplicemente “lanciati oltre il muro” e lo stato finale era, molto semplicemente, lo stato finale, senza alcuna ragionevole possibilità di aggiornamenti, patch o correzioni. Nessuno di questi casi si applica al software aziendale moderno (con solo le più rare eccezioni).

Lo sviluppo del software è grosso modo un continuum. I normali processi di sviluppo prevedono che il nuovo software venga costruito sopra il vecchio, direttamente (creando aggiornamenti a una base di codice esistente) o indirettamente (ricostruendo sulla base delle conoscenze acquisite dall’aver costruito una versione precedente del software). L’idea è che ogni versione successiva del software sia superiore a quella che la precede. Questo non è garantito, ovviamente: esistono concetti come gli errori di regressione e semplicemente uno sviluppo scadente, ma in linea di massima il software migliora nel tempo – specialmente quando parliamo di software di classe enterprise utilizzato nelle aziende e in sviluppo attivo. Il nuovo software non è solo la fase successiva del vecchio software, ma rappresenta anche, in quasi tutti i casi, lo stato attuale di patch, correzioni di bug, aggiornamenti e, ove necessario, cambiamenti di approccio o di tecnica. Il nuovo software, proveniente da aziende di qualità, è quasi esclusivamente migliore del vecchio software. Il software si evolve e matura.

Oltre alla qualità del software in sé, vi è il concetto di investire nel futuro. Il software non è qualcosa che può rimanere sullo scaffale per sempre. Deve rimanere, in una certa misura, aggiornato, altrimenti smette di funzionare perché la piattaforma su cui gira cambia, emerge qualche nuovo elemento, vengono scoperte falle di sicurezza o le esigenze cambiano. Installare software vecchio significa investire nel passato, investire nell’installare, imparare, utilizzare e supportare tecnologie obsolete. Questo si chiama “debito tecnico”. Questa vecchia tecnologia potrebbe durare anni o persino decenni, ma il software vecchio perde valore nel tempo e diventa sempre più costoso da supportare, sia per i fornitori, se continuano a supportarlo, sia per gli utenti finali, che devono supportarlo.

Lo stesso concetto di debito tecnico si applica ai fornitori di software in questione. Vi è un costo molto elevato nel creare software e, in particolare, nel mantenere più versioni dello stesso. I fornitori di software hanno forti incentivi a ridurre il supporto per le versioni più vecchie per concentrare le risorse sulle release software attuali (questo è uno dei motivi principali per cui le distribuzioni SaaS sono così popolari: il fornitore controlla le versioni disponibili e può eliminare le versioni legacy tramite gli aggiornamenti). Se i clienti richiedono il supporto per le vecchie versioni, il costo deve essere assorbito da qualche parte e spesso viene assorbito sia in termini di impatto economico su tutti i clienti, sia come una diminuzione dell’attenzione sul nuovo prodotto, poiché i team di sviluppo devono essere divisi per supportare il patching delle vecchie versioni oltre a sviluppare quella nuova. Maggiore è lo sforzo che deve essere dedicato alle vecchie versioni, minore è quello che può essere impiegato in nuovi miglioramenti.

All’interno del quadro di quanto ho già detto, è importante parlare di maturità del codice. Spesso la maturità del codice viene addotta come motivo per distribuire “codice vecchio”, ma ritengo che questo sia un fraintendimento, da parte dell’IT, dei processi di sviluppo software. Se pensiamo a una linea di codice rilasciata, il fatto che sia rilasciata e in uso non la rende realmente più matura. Il codice non cambia in natura, semplicemente sta lì. La sua maturità è “bloccata” il giorno in cui viene rilasciato. Se viene applicata una patch, allora sì, “maturerebbe” dopo il rilascio. Le versioni successive dello stesso software, basate sulla stessa base di codice ma più aggiornate, sono il codice veramente più “maturo”, poiché è stato rivisto, aggiornato, testato, ecc. in misura maggiore rispetto alla prima release dello stesso codice.

Questo è controintuitivo rispetto, ad esempio, a un’automobile in cui ogni rilascio è una cosa nuova con nuove possibilità di problemi meccanici e diverse preoccupazioni in termini di affidabilità – dove aspettare qualche anno offre la possibilità di vedere quali problemi di affidabilità emergono. Il software non è così. Quindi il concetto di volere software più maturo dovrebbe spingerti a distribuire il software “più recente e migliore” piuttosto che quello “collaudato e affidabile”.

Se pensiamo ai numeri di versione del software piuttosto come a delle età, la cosa emerge. Linux 3.1 è molto più vecchio, in termini di maturazione del software, di Linux 2.4. Ha un decennio di sviluppo aggiuntivo.

Usiamo un esempio reale molto attuale oggi. Sei in un’azienda che sta per installare i suoi primi server. È appena uscito Windows Server 2012 R2. Dovresti installare Windows Server 2008, 2008 R2 (2010), Server 2012 o Server 2012 R2 (fine 2013)?

A molte aziende, questo suona come se stessimo parlando di tra due e quattro prodotti completamente diversi, che probabilmente hanno motivi differenti per cui sceglierne ciascuno. Questo, in linea di massima, è falso. Ogni versione più recente è semplicemente un upgrade, un aggiornamento, una patch e un incremento di funzionalità rispetto alla precedente. Ciascuna, a sua volta, è più avanzata e matura di quella che la precede. Ogni nuova versione beneficia del lavoro svolto sulla release originale della sua predecessora, oltre alle correzioni di bug, alle patch e alle aggiunte di funzionalità realizzate nell’intervallo tra la release originale e quella successiva. Ogni nuova release è, in realtà, una “release minore” di quella precedente. Se guardiamo i numeri di revisione del kernel, anziché i nomi di marketing delle release, la cosa potrebbe avere più senso.

Windows Server 2008 era Windows NT 6.0. Windows Server 2008 R2 era Windows NT 6.1, evidentemente una revisione minore o persino una “patch” della release precedente. Windows Server 2012 era Windows NT 6.2 e il nostro attuale Windows Server 2012 R2 è Windows NT 6.3. Se usassimo i numeri di revisione anziché i nomi di marketing, suonerebbe quasi folle installare intenzionalmente una versione vecchia, meno matura, meno aggiornata e con meno patch. Vogliamo gli aggiornamenti più recenti, le correzioni di bug più recenti e che i problemi di sicurezza più recenti siano stati affrontati.

Per le nuove distribuzioni software, più recente è il software installato, migliore è l’opportunità di sfruttare le funzionalità più recenti e il maggiore tempo a disposizione prima che l’inevitabile obsolescenza si faccia sentire. Tutto il software invecchia, quindi installare software più recente offre le migliori probabilità che quel software duri più a lungo. Fornisce la migliore flessibilità per il futuro sconosciuto.

Seguire questa linea di pensiero potrebbe portarci a ritenere che abbia senso distribuire anche software in versione pre-release o persino beta. E sebbene possano esistere casi specifici in cui questo abbia senso, come nei “gruppi di test” per valutare il software prima di rilasciarlo all’azienda nel suo complesso, in generale non lo ha. La natura del software pre-release è che non è supportato e può contenere codice che non lo sarà mai. Utilizzare tale codice in modo isolato può essere vantaggioso, ma per l’uso generale non è consigliabile. Vi sono importanti processi che vengono seguiti tra le release preview o beta e le release finali del codice, indipendentemente dal livello di maturità complessivo del prodotto.

Questo ci porta all’altra situazione, quella in cui stiamo aggiornando software esistente. Questo, ovviamente, è uno scenario completamente diverso da un’installazione da zero e i fattori coinvolti sono molti, molti di più.

Uno dei fattori più importanti nella maggior parte delle situazioni è quello delle licenze. Aggiornare regolarmente il software può comportare costi di licenza che devono essere considerati nell’equazione tra benefici e costi. Alcuni prodotti, come la maggior parte del software open source, non hanno questo costo e possono essere aggiornati non appena sono disponibili nuove versioni.

L’altro fattore davvero rilevante nell’aggiornamento del software è il costo dello sforzo umano richiesto per l’aggiornamento – a differenza di un’installazione da zero, in cui lo sforzo di installazione è di fatto equivalente tra software vecchio e nuovo. In realtà, il nuovo software tende a essere più facile da installare del vecchio software, semplicemente grazie a miglioramenti e progressi. Mantenere una singola versione del software per un decennio significa che, durante quel periodo, le risorse non sono state dedicate ai processi di aggiornamento. Aggiornare annualmente durante quel periodo significa che le risorse sono state impiegate dieci volte per eseguire aggiornamenti separati. Questo rende molto più difficile giustificare il costo dell’aggiornamento. Ma c’è di più del semplice sforzo del processo di aggiornamento in sé: c’è anche la formazione continua necessaria per gli utenti finali, che saranno costretti a sperimentare più cambiamenti, più spesso, attraverso aggiornamenti costanti.

Questo potrebbe far sembrare l’aggiornamento del software un fattore negativo, ma non lo è. È semplicemente un’equazione in cui ciascun lato deve essere soppesato. Gli aggiornamenti regolari spesso significano cambiamenti piccoli e incrementali anziché grandi salti, consentendo agli utenti finali di adattarsi in modo più naturale. Gli aggiornamenti regolari significano che i processi di aggiornamento sono spesso più facili e prevedibili. Gli aggiornamenti regolari significano che il debito tecnico è sempre gestito e che i benefici delle versioni più recenti – che possono essere funzionalità, efficienze o miglioramenti della sicurezza – sono disponibili prima, consentendo di sfruttarli per un periodo più lungo.

Prendendo ciò che abbiamo appreso dai due scenari precedenti, tuttavia, vi è un altro importante insegnamento da trarre. Una volta presa la decisione di eseguire un aggiornamento, la domanda è spesso “a quale versione aggiorniamo?”. In realtà, però, ogni aggiornamento che vada oltre un normale processo di patching è davvero come una decisione d’acquisto in miniatura di “nuovo software”, e la logica per cui “sempre” installiamo la versione più recente disponibile quando facciamo un’installazione da zero si applica anche qui. Quindi, quando si esegue un aggiornamento, dovremmo quasi sempre aggiornare il più possibile – auspicabilmente alla versione attuale.

Per applicare di nuovo l’esempio Microsoft, possiamo prendere un’organizzazione che oggi ha distribuito Windows XP. L’azienda decide di investire in un ciclo di aggiornamento verso una versione più recente, non solo nel proseguimento del patching. Vi sono diverse versioni della piattaforma desktop Windows ancora sotto supporto attivo da parte di Microsoft. Tra queste vi sono Windows Vista, Windows 7, Windows 8 e Windows 8.1. Aggiornare a una delle versioni meno recenti comporta meno tempo prima della fine del ciclo di vita di quella versione, il che aumenta il rischio organizzativo; utilizzare versioni più vecchie significa un investimento continuo in tecnologie già obsolete, il che comporta un aumento del debito tecnico e un minore accesso a nuove funzionalità che potrebbero rivelarsi vantaggiose una volta disponibili. In questo particolare esempio, le versioni più recenti sono anche considerate più sicure e richiedono meno risorse hardware.

Ogni azienda deve trovare il giusto equilibrio per sé per quanto riguarda i cicli di aggiornamento del software esistente. Ogni azienda e ogni pacchetto software è diverso. Il software enterprise come Microsoft Windows, Microsoft Office o un Oracle Database segue molto bene questi modelli. I piccoli progetti software e quelli che rientrano nell’ambito su misura possono avere un ciclo di rilascio più dinamico e imprevedibile, ma in genere seguiranno comunque la maggior parte di queste regole. Considera di applicare empatia al processo di sviluppo del software per comprendere come tu e il tuo fornitore di software potete collaborare al meglio per offrire il massimo valore alla tua organizzazione, e combina questo con la tua esigenza di ridurre il debito tecnico per sfruttare il tuo investimento software nel miglior modo possibile per la tua organizzazione.

Ma le regole pratiche sono relativamente semplici:

Quando distribuisci nuovo software o aggiorni, punta alla versione ragionevolmente più recente del software. Sfrutta ogni opportunità di distribuzione per eliminare il più possibile il debito tecnico.

Quando il software esiste già, soppesa fattori come lo sforzo umano, i costi di licenza, la coerenza ambientale e i test di compatibilità rispetto ai benefici in termini di funzionalità, prestazioni e debito tecnico.