Hai mai visitato un sito web e trovato il messaggio “Sito in manutenzione, torni più tardi”? Se sei un’azienda, questo messaggio ha un costo preciso: clienti che abbandonano, ordini persi, reputazione scalfita. Il downtime — anche solo di 10 minuti — può fare danni reali e concreti.
Eppure molte aziende accettano ancora il downtime come un male necessario ogni volta che bisogna aggiornare il software. Non è così. Con le tecniche e gli strumenti giusti, è possibile aggiornare una web app senza mai spegnerla. Si chiama deploy senza downtime, o zero-downtime deployment, e in questo articolo spiego cos’è, come funziona e come lo applico nei miei progetti reali.
Perché il downtime è un problema serio per le aziende
Per una piccola azienda, 30 minuti di sito irraggiungibile possono sembrare poca cosa. Ma facciamo i conti:
- Un e-commerce con 50 ordini al giorno perde circa 1 ordine ogni 29 minuti di downtime.
- Un sistema di prenotazione offline durante le ore di punta può costare decine di appuntamenti mancati.
- Un gestionale aziendale fermo blocca il lavoro di tutti i dipendenti contemporaneamente.
E poi c’è il danno alla reputazione: il cliente che trova il sito offline non sa se è un problema temporaneo o se l’azienda ha chiuso i battenti. Nel dubbio, cerca la concorrenza.
Per questo motivo, qualsiasi sistema in produzione — web app, portale clienti, piattaforma SaaS, e-commerce — dovrebbe essere aggiornato senza fermarsi mai.
Che cos’è il deploy senza downtime
Il deploy senza downtime è una strategia di aggiornamento software in cui la nuova versione dell’applicazione viene resa disponibile agli utenti prima che quella vecchia venga spenta. In questo modo, dall’esterno, il servizio non ha mai un momento di interruzione visibile.
Esistono diverse tecniche per ottenerlo, ognuna adatta a contesti e dimensioni differenti.
Blue/Green Deployment
Si mantengono due ambienti identici: blue (quello attivo con la versione corrente) e green (quello dove viene deployata la nuova versione). Quando il green è pronto e testato, il traffico viene spostato dal blue al green in pochi secondi, senza interruzioni. In caso di problemi, il rollback è immediato: basta tornare al blue.
È la tecnica più sicura per applicazioni critiche. L’unico “costo” è che richiede temporaneamente il doppio delle risorse computazionali durante il deploy — ma solo per pochi minuti.
Rolling Update
La nuova versione viene applicata gradualmente, un’istanza alla volta. Mentre alcune istanze dell’applicazione servono ancora la versione vecchia, altre vengono aggiornate. Il traffico viene distribuito tra le due versioni durante la transizione fino a che tutte le istanze sono aggiornate.
È la tecnica standard in ambienti orchestrati come Kubernetes. Richiede che il codice sia compatibile con entrambe le versioni del database durante la finestra di transizione — un aspetto da progettare con attenzione.
Canary Release
Una variante più sofisticata: la nuova versione viene esposta inizialmente solo a una piccola percentuale di utenti reali (es. il 5%). Se tutto funziona correttamente, la percentuale aumenta progressivamente fino al 100%. Se emergono errori, il rollout si ferma prima che colpisca l’intera base utenti.
Ideale per feature ad alto rischio o per applicazioni con migliaia di utenti attivi simultaneamente.
Come applico il deploy senza downtime nei miei progetti
Nella mia infrastruttura, la maggior parte delle web app che sviluppo e gestisco gira su Docker, orchestrato tramite Portainer. Questo mi permette di applicare il deploy senza downtime in modo semplice e ripetibile, anche su server di piccole e medie dimensioni, senza dover investire in infrastrutture enterprise costose.
Il meccanismo che utilizzo più spesso è simile al blue/green, ottimizzato per container:
- Costruisco la nuova immagine Docker con il codice aggiornato e la carico nel registry.
- Avvio il nuovo container, lasciando attivo quello con la versione precedente.
- Il reverse proxy (nginx) viene reindirizzato verso il nuovo container.
- Verifico che tutto funzioni correttamente tramite health check e monitoraggio.
- Solo a quel punto, il vecchio container viene spento.
L’intera operazione richiede tipicamente meno di 30 secondi. Per l’utente finale, non c’è nessuna interruzione visibile, nessun errore, nessun messaggio di manutenzione.
Il caso tandemOPS
tandemOPS è una web app di monitoraggio IT che sviluppo e opero direttamente. Viene aggiornata con regolarità — nuove funzionalità, correzioni, ottimizzazioni — e grazie all’architettura containerizzata ogni rilascio avviene senza che gli utenti connessi perdano la sessione o vedano errori. La pipeline di deploy è automatizzata: a ogni push sul branch principale, il sistema costruisce la nuova immagine, avvia il container aggiornato e spegne quello vecchio in sequenza.
Il caso Apicco
Apicco è un gestionale web all-in-one per aziende di servizi. Essendo uno strumento usato attivamente durante la giornata lavorativa — con operatori che inseriscono dati, gestiscono appuntamenti e generano documenti — il downtime durante gli aggiornamenti sarebbe assolutamente inaccettabile. Con l’architettura Docker + Portainer, ogni aggiornamento avviene in modo completamente trasparente: gli utenti non si accorgono di nulla.
Il punto critico: le migrazioni del database
Uno degli aspetti più delicati del deploy senza downtime riguarda le migrazioni del database. Se una nuova versione del codice richiede una modifica alla struttura del database — aggiunta di una colonna, rinomina di un campo, modifica di un indice — bisogna fare attenzione: durante la transizione, il vecchio e il nuovo codice coesistono e devono entrambi funzionare sullo stesso database.
La soluzione è il deploy multi-fase, basato sulla retrocompatibilità:
- Fase 1: aggiorna il database in modo backward-compatible (aggiungi la nuova colonna senza eliminare quella vecchia).
- Fase 2: deploya il nuovo codice che usa la nuova struttura.
- Fase 3 (successiva): rimuovi la struttura obsoleta del database una volta che il vecchio codice è completamente dismesso.
Richiede una pianificazione più attenta, ma è l’unico modo per garantire che le migrazioni non causino errori agli utenti durante il deploy.
Monitoraggio post-deploy: non basta fare il deploy
Un deploy senza downtime non significa un deploy senza attenzione. Dopo ogni rilascio, è fondamentale monitorare attivamente:
- Il tasso di errori HTTP (500, 502, 503).
- I tempi di risposta — un aumento improvviso della latenza può indicare un problema.
- I log applicativi per eccezioni inattese.
- Le metriche di business: se le conversioni o le prenotazioni calano subito dopo un deploy, è un segnale.
Nei progetti che gestisco, utilizzo sistemi di monitoraggio uptime e alerting integrati nell’infrastruttura self-hosted. Se qualcosa non va dopo un deploy, ricevo una notifica in tempo reale e posso eseguire il rollback prima che l’impatto sugli utenti diventi significativo.
Vale la pena investire nel deploy senza downtime?
Dipende dal contesto. Se hai un sito vetrina aggiornato una volta all’anno, probabilmente no. Ma se la tua azienda gestisce uno di questi sistemi:
- una web app usata quotidianamente da clienti o dipendenti;
- un e-commerce con traffico costante;
- un gestionale o portale con sessioni attive durante l’orario lavorativo;
- una piattaforma SaaS con utenti su più fusi orari;
…allora il deploy senza downtime non è un lusso: è una necessità operativa.
Il costo per implementarlo è relativamente contenuto, specialmente con un’architettura basata su container Docker. E una volta configurata correttamente l’infrastruttura, ogni aggiornamento successivo è rapido, sicuro e completamente invisibile agli utenti.
Come posso aiutarti
Se hai una web app, un e-commerce o un gestionale che vuoi aggiornare senza interruzioni — o se vuoi migrare da un’infrastruttura tradizionale a una basata su container con deploy automatizzato — posso aiutarti a progettare e implementare la soluzione giusta per la tua situazione specifica.
Sviluppo e gestisco applicazioni web per aziende italiane ed europee, occupandomi sia del codice che dell’infrastruttura: dal server al deploy, dalla pipeline CI/CD al monitoraggio. Se il tuo sistema non può permettersi interruzioni, parliamo di come garantirlo.
→ Contattami per una consulenza senza impegno
