Ripensare le release a supporto a lungo termine

Tradizionalmente le release dei sistemi operativi a supporto a lungo termine sono state il baluardo delle implementazioni enterprise. Questo è il modello utilizzato da IBM, Oracle, Microsoft, Suse e Red Hat ed è stato il pensiero convenzionale riguardo ai sistemi operativi fin dall’inizio delle offerte di supporto, molti decenni fa.

In passato è stato comune sia per i server sia per le release dei sistemi operativi desktop seguire questo modello, ma nello specifico ambito di Linux abbiamo iniziato a vedere questo schema messo in discussione, là dove prodotti meno formali erano liberi di sperimentare release più rapide, non supportate o semplicemente non strutturate. Nell’ambito dei prodotti principali, openSuse, Fedora e Ubuntu offrivano tutti soluzioni a supporto a breve termine o a rilascio rapido. Invece di cicli di rilascio misurati in anni e cicli di supporto che si avvicinavano a un decennio, hanno accorciato i cicli di rilascio a mesi e il supporto a soli mesi o, al massimo, a pochi anni.

Nell’ambito desktop, ottenere nuove funzionalità e applicazioni prima, invece di concentrarsi principalmente sulla stabilità come era comune sui server, aveva spesso senso e portava con sé il vantaggio aggiuntivo che nuove tecnologie o approcci potessero essere testati su prodotti con cicli di rilascio più rapidi prima di essere integrati nei prodotti server a supporto a lungo termine. Fedora, per esempio, è un banco di prova per tecnologie che, dopo essersi dimostrate valide, faranno il loro ingresso nelle release di Red Hat Enterprise Linux. Usando Fedora, gli utenti finali ottengono prima le funzionalità, possono conoscere prima le tecnologie di RHEL e Red Hat può testare i prodotti su larga scala prima di distribuirli su server critici.

Nel tempo la stabilità delle release a breve termine è migliorata drasticamente e sempre più questi sistemi sono visti come opzioni valide per i sistemi server. Questi sistemi ricevono prima nuovi miglioramenti, funzionalità e aggiornamenti, cosa che è spesso considerata vantaggiosa.

Un grande vantaggio di qualsiasi sistema operativo è il suo ecosistema di supporto, inclusi i pacchetti e le librerie supportati e forniti come parte del sistema operativo di base. Con le release a lungo termine, vediamo spesso pacchetti critici invecchiare drasticamente nel corso della vita della release, il che può causare problemi di prestazioni, compatibilità e, in casi estremi, persino di sicurezza. Ciò costringe ovviamente gli utenti dei sistemi operativi con release a lungo termine a scegliere tra continuare a convivere con i limiti dei componenti più datati oppure integrare da sé nuovi componenti, cosa che spesso vanifica il valore fondamentale del prodotto a release a lungo termine.

Poiché l’obiettivo di una release a lungo termine è avere stabilità e test di integrazione, sostituire componenti all’interno del prodotto per “aggirare” i limiti di una LTS significa che quei componenti non vengono trattati in modo LTS e che i test di integrazione da parte del fornitore, molto probabilmente, non avvengono più, o, se avvengono, non nella stessa misura. In pratica, ciò che accade è che questo diventa un prodotto a release a breve termine costruito in proprio, ma con componenti core obsoleti e con minore controllo.

In realtà, sotto la maggior parte degli aspetti, fare questo è peggio che passare direttamente a un prodotto a release a breve termine. Usare un prodotto a release a breve termine o a rilascio rapido consente al fornitore di mantenere i test e l’integrazione presupposti, semplicemente con un ciclo di rilascio e supporto più rapido, così che il valore generale del concetto di release a lungo termine sia preservato e con tutti i componenti del sistema operativo aggiornati, anziché solo alcuni. Ciò consente una maggiore standardizzazione, test su scala industriale e conoscenza e integrazione condivise rispetto a un modello LTS parziale.

Forse è giunto il momento di ripensare il valore del supporto a lungo termine per i sistemi operativi. Per troppo tempo, a quanto pare, il valore di questo approccio è stato semplicemente dato per scontato e seguito, e certamente aveva e ha i suoi meriti; ma il mondo dei sistemi operativi è cambiato da quando questo approccio è stato introdotto per la prima volta. La necessità di aggiornamenti è aumentata, mentre i tassi di cambiamento di elementi come i kernel e le librerie sono rallentati drasticamente. Server più potenti hanno spostato la compatibilità più in alto nello stack e, invece di essere scritto per un sistema operativo, il software è spesso scritto per una versione specifica di un linguaggio, di un runtime o di un altro livello di astrazione.

Cicli di rilascio più brevi significano che i sistemi ricevono funzionalità, dall’alto verso il basso, più di frequente. Gli aggiornamenti tra release “principali” sono più piccoli e meno impattanti. Le modifiche derivanti dagli aggiornamenti sono più graduali, offrendo una curva di apprendimento e adattamento più organica. E, cosa più importante, la necessità di sostituire componenti di sistema accuratamente testati e integrati con versioni fornite da terze parti diventa, di fatto, qualcosa di inaudito.

La stabilità per i fornitori di software resta un valore delle release a lungo termine e farà sì che vi sia la necessità di utilizzare release a lungo termine ancora a lungo. Ma per l’amministratore di sistema, il valore di questo approccio sembra diminuire e, a mio parere personale, ha trovato un punto di svolta negli ultimi anni. Un tempo sembrava previsto e normale attendere due o tre anni perché i pacchetti venissero aggiornati, ma oggi ciò appare inutilmente macchinoso. Sembra sempre più comune che i componenti di livello superiore siano costruiti con il requisito di componenti sottostanti più recenti; un’aspettativa che i sistemi operativi siano più aggiornati oppure che porzioni del sistema operativo vengano aggiornate separatamente dal resto.

Un forte ricorso alle tecnologie di containerizzazione potrebbe in qualche modo invertire questa tendenza, ma in modi che riducono comunque, al contempo, il valore delle release a lungo termine. La containerizzazione riduce la necessità di estese funzionalità nel sistema operativo di base, rendendo più facile ed efficace aggiornare più frequentemente per un migliore supporto a kernel, filesystem, driver e container, lasciando al contempo le librerie e le altre dipendenze all’interno dei container, consentendo così di soddisfare in quel modo le applicazioni che necessitano di dipendenze a supporto a lungo termine e di gestire in quella maniera le applicazioni che possono beneficiare di componenti più recenti.

Naturalmente la virtualizzazione ha avuto un ruolo nel ridurre il valore dei modelli a supporto a lungo termine, rendendo banali il ripristino rapido e la duplicazione dei sistemi. La stabilità per la quale abbiamo avuto bisogno delle release a supporto a lungo termine è in parte garantita dal livello di virtualizzazione; l’astrazione hardware migliora la stabilità dei driver in modi molto importanti. Allo stesso modo, anche i modelli di supporto in stile DevOps riducono la necessità di supporto a lungo termine e rendono gli ecosistemi server più agili e flessibili. Le tendenze nei paradigmi di amministrazione dei sistemi tendono a favorire sistemi operativi più moderni.

Solo il tempo dirà se le tendenze continueranno nella direzione verso cui sono dirette. Per quanto mi riguarda, quest’ultimo anno è stato illuminante e mi ha visto spostare i miei carichi di lavoro, dopo un decennio di fermo sostegno a prodotti con supporto a lunghissimo termine, verso prodotti a rilascio rapido e, devo dire, sono molto soddisfatto del cambiamento.