Zero Downtime: come aggiornare sistemi che non possono mai fermarsi?

Ogni sistema deve evolversi. Aggiornamenti di sicurezza, nuove funzionalità, correzioni di bug e miglioramenti delle prestazioni fanno naturalmente parte del suo ciclo di vita.

Ma cosa succede quando un sistema non può essere messo offline per essere aggiornato?

Per una piattaforma utilizzata in modo continuo, anche pochi minuti di interruzione possono avere un impatto su migliaia di utenti e sui processi che dipendono da essa.

È qui che entra in gioco il Zero Downtime: la capacità di aggiornare un sistema senza interrompere il servizio.

Come si aggiorna un sistema mentre continua a essere utilizzato?

Nel modello tradizionale, il processo è relativamente semplice: il sistema viene messo offline, viene distribuita la nuova versione, vengono eseguiti i controlli necessari e infine il servizio torna disponibile.

Ma per i sistemi che devono rimanere costantemente operativi, questo approccio non è sempre possibile.

Invece di disattivare immediatamente la versione esistente, la nuova versione può essere distribuita parallelamente.

Mentre gli utenti continuano a utilizzare il sistema esistente, la nuova versione può essere testata e il traffico può essere reindirizzato gradualmente verso di essa.

Dal punto di vista dell’utente, il passaggio può risultare quasi impercettibile.

Un aggiornamento non deve necessariamente raggiungere tutti nello stesso momento

Uno dei modi per ridurre il rischio è evitare di distribuire immediatamente una nuova versione a tutti gli utenti.

Inizialmente può essere resa disponibile soltanto a una piccola parte del traffico.

Se tutto funziona come previsto, la distribuzione può essere estesa gradualmente. Se invece emerge un problema, il processo può essere interrotto prima che coinvolga l’intero sistema.

In questo modo, l’aggiornamento passa dall’essere un singolo evento ad alto rischio a un processo graduale e controllato.

La sfida va oltre il codice

Una nuova versione di un’applicazione può spesso essere distribuita in tempi relativamente brevi. Ma un sistema raramente è composto soltanto dall’applicazione.

Ci sono database, API, integrazioni, altri servizi e processi che devono continuare a comunicare durante tutta la transizione da una versione all’altra.

Per questo motivo, la versione esistente e quella nuova possono dover funzionare in parallelo per un determinato periodo di tempo.

Gli aggiornamenti devono quindi essere considerati fin dalla progettazione dell’architettura del sistema, non soltanto nel momento in cui una nuova versione è pronta per essere pubblicata.

Anche tornare alla versione precedente fa parte del processo di aggiornamento

Non tutte le nuove versioni funzionano sempre esattamente come previsto.

Un processo di distribuzione ben progettato deve quindi prevedere non soltanto il passaggio alla nuova versione, ma anche la possibilità di tornare rapidamente a quella precedente in caso di problemi.

Se il ripristino richiede interventi lunghi e complessi, aumenta il rischio associato a ogni cambiamento.

Per i sistemi che funzionano in modo continuo, la capacità di tornare rapidamente a una versione stabile può essere importante quanto quella di distribuirne una nuova.

Zero Downtime non significa che nulla possa andare storto

L’obiettivo non è costruire un sistema in cui sia impossibile che si verifichino problemi.

Una promessa del genere non sarebbe realistica.

L’obiettivo è introdurre i cambiamenti in modo controllato, limitare l’impatto di eventuali problemi e mantenere il servizio disponibile per gli utenti.

Più un sistema è critico, meno la sua continuità dovrebbe dipendere dal fatto che ogni aggiornamento vada perfettamente.

I sistemi che non si fermano mai devono essere progettati diversamente

Il Zero Downtime non è una funzionalità che può essere semplicemente aggiunta alla fine di un progetto.

Dipende dall’architettura, dall’infrastruttura, dall’automazione, dal modo in cui vengono gestiti i dati e da come vengono distribuite le nuove versioni.

Se un sistema deve funzionare 24 ore su 24, 7 giorni su 7, anche il modo in cui cambia ed evolve deve essere progettato tenendo conto della stessa esigenza.

Come afferma Ermal Beqiri, fondatore di ALSoft:

“Un sistema che deve essere sempre disponibile non può fermarsi ogni volta che deve essere migliorato. Gli aggiornamenti devono essere parte del modo in cui il sistema viene progettato fin dall’inizio.”

In ALSoft, consideriamo i sistemi progettati per il lungo periodo come strutture capaci di evolversi senza perdere continuità. Il Zero Downtime rientra in questa logica: creare spazio per il miglioramento e l’evoluzione senza trasformare ogni cambiamento in un’interruzione per l’utente.