«Dobbiamo andare in cloud?» è una domanda che sento porre spesso in questo modo, come se l'azienda dovesse scegliere una volta per tutte da che parte stare. È la domanda sbagliata, e porta quasi sempre a decisioni che vengono rimpiante: migrazioni fatte per moda e poi riportate indietro, oppure server tenuti in azienda per abitudine ben oltre il momento in cui avevano senso. La domanda utile non riguarda l'azienda: riguarda un sistema alla volta. Non «siamo un'azienda cloud o on-premise», ma «questo gestionale, questo archivio, questa posta elettronica, dove conviene che stiano, e perché».
In questo articolo metto in fila i criteri con cui la scelta si può fare in modo argomentato: che cosa cambia davvero tra le opzioni, come si confrontano i costi senza illudersi, quali voci sfuggono sistematicamente al confronto e come si conduce la decisione in una PMI, dove nessuno ha tempo per progetti infiniti.
Le quattro opzioni, e che cosa cambia davvero
Sotto le etichette commerciali ci sono quattro modi concreti di far vivere un sistema informatico, e si distinguono per una cosa sola: quanto lavoro resta in capo all'azienda.
- On-premise: i server stanno in azienda (o in un armadio in un datacenter). L'azienda possiede l'hardware e se ne occupa: alimentazione, guasti, aggiornamenti, sicurezza, ricambi.
- Hosting o cloud privato: le macchine sono dedicate all'azienda ma vivono da un fornitore, che si occupa del ferro e della connettività. Il sistema operativo e le applicazioni restano un problema aziendale.
- Cloud pubblico (IaaS): si affittano risorse di calcolo e storage su infrastruttura condivisa. Si paga il consumo, si accende e si spegne in minuti, ma i sistemi che ci girano sopra restano da gestire.
- SaaS: si usa un servizio già pronto — la posta, il gestionale, il CRM — e del funzionamento si occupa interamente il fornitore. All'azienda restano i dati, gli accessi e le configurazioni. Che non è poco: è esattamente la parte in cui accadono gli incidenti.
Questo schema mostra come si sposta il confine delle responsabilità. È il grafico più utile da tenere a mente, perché smonta l'equivoco più diffuso: che passare al cloud significhi «non doversene più occupare».
Quella prima riga è il punto che vale la pena rileggere. Chi entra nella posta aziendale, quali permessi ha, chi mantiene le copie dei dati, chi si accorge di un accesso anomalo: sono domande che il fornitore non risolve al posto dell'azienda in nessuno dei quattro scenari. È il motivo per cui una migrazione al cloud fatta bene non riduce il bisogno di governo dell'IT — lo sposta su altre attività.
Il criterio: si sceglie per carico di lavoro, non per azienda
Nelle PMI che seguo, l'infrastruttura non è mai una cosa sola. C'è il gestionale, ci sono gli archivi condivisi, c'è la posta, ci sono due o tre applicativi verticali, spesso una macchina che pilota qualcosa in produzione e un paio di sistemi che nessuno tocca da anni perché «funzionano». Ognuno di questi ha esigenze diverse, e trattarli come un blocco unico è ciò che rende le migrazioni costose e deludenti.
Per ogni sistema, quattro domande separano i casi facili da quelli che richiedono analisi.
Il carico è costante o variabile? Un gestionale usato da trenta persone dalle otto alle diciotto consuma sempre le stesse risorse: è un carico prevedibile, e ciò che è prevedibile conviene quasi sempre possederlo. Un e-commerce che triplica il traffico in tre settimane l'anno è l'esatto opposto: dimensionare hardware sul picco significa pagare tutto l'anno una capacità che serve per venti giorni.
I dati possono uscire dall'azienda? Non è quasi mai una questione di legge — il cloud è pienamente compatibile con il GDPR se il fornitore è adeguato e il contratto è in ordine — quanto di contratti con i clienti, di requisiti di filiera e di scelte del titolare. Se un cliente impone che i suoi progetti restino su sistemi in Italia, quella clausola vale più di ogni considerazione tecnica.
Serve accesso locale e immediato? Ci sono sistemi che devono stare fisicamente vicino a chi li usa: macchinari collegati alla rete di produzione, archivi CAD da decine di gigabyte che si aprono decine di volte al giorno, sistemi che devono continuare a funzionare anche quando la linea internet cade. Se un fermo della connettività blocca la produzione, il tema non è più informatico: è di continuità operativa.
Esiste già un servizio pronto? Per posta, collaborazione, firma digitale, videoconferenza, antivirus gestito, la risposta è sì da anni. Costruirsi in casa qualcosa che esiste come servizio maturo è un modo per pagare due volte: la prima in licenze e hardware, la seconda in tempo di gestione.
I costi: perché il confronto quasi sempre è sbagliato
Il confronto economico che vedo fare più spesso mette a sinistra il preventivo dei server e a destra il canone mensile del cloud, moltiplicato per dodici. È un confronto che non regge, per due motivi: ignora la differenza tra un investimento e un costo ricorrente, e dimentica metà delle voci.
Un server acquistato è un investimento che si esaurisce nel tempo: si paga una volta, si ammortizza in tre-cinque anni, poi va sostituito. Il cloud è un costo che si ripete all'infinito, ma non chiede capitale iniziale. Su un orizzonte breve il cloud vince quasi sempre; man mano che ci si allontana, la curva si inverte — e il punto in cui le due linee si incrociano è l'informazione che serve davvero.
La regola pratica che uso è semplice: se un sistema resterà in vita più a lungo del punto di pareggio, possederlo conviene; se ha vita incerta o breve, affittarlo conviene. Un archivio documentale che l'azienda terrà per dieci anni e un ambiente di test che vivrà tre mesi meritano decisioni opposte, anche se la tecnologia sottostante è la stessa.
Le voci che spariscono dal confronto
Ci sono costi che nei preventivi non compaiono e che nella realtà si presentano puntualmente. Dal lato cloud: il traffico dei dati in uscita, che sui grandi volumi pesa; lo storage a lungo termine, molto più caro del disco locale quando si parla di anni di archivio; le licenze software, che in cloud spesso hanno condizioni diverse; il costo della migrazione, che è un progetto vero con ore di lavoro e rischi; e la crescita silenziosa del canone, perché le risorse si accendono facilmente e si spengono raramente.
Dal lato on-premise, altrettanti: il gruppo di continuità e la sua manutenzione; il contratto di assistenza sull'hardware con i tempi di intervento; le licenze di virtualizzazione, il cui costo è cambiato parecchio negli ultimi anni; lo spazio fisico e il condizionamento; il tempo di chi aggiorna, controlla e sostituisce; e soprattutto il costo di essere fermi quando qualcosa si rompe e il pezzo di ricambio arriva in tre giorni.
Nessuna delle due colonne è quella «furba». Ma un confronto che dimentica queste voci non è un confronto: è una preferenza già decisa, vestita da analisi.
Quello che il cloud non elimina
Tre convinzioni ricorrenti meritano di essere corrette, perché portano ad abbassare la guardia proprio dove servirebbe alzarla.
«Nel cloud il backup lo fa il fornitore.» Quasi sempre il fornitore garantisce la disponibilità del proprio servizio, non il recupero dei dati che l'azienda cancella o si fa cifrare. Per la posta e i file in SaaS, la conservazione predefinita è spesso di poche settimane. Se un dipendente svuota una cartella condivisa e nessuno se ne accorge per due mesi, il fornitore non ha nulla da restituire. È un tema che approfondisco nell'articolo sul test di ripristino dei backup.
«Nel cloud siamo più sicuri.» L'infrastruttura di un grande provider è sicuramente più protetta di un armadio in ufficio. Ma la maggior parte degli incidenti non passa dall'infrastruttura: passa da una credenziale rubata, da un permesso troppo largo, da una condivisione lasciata aperta. Spostare i sistemi in cloud senza mettere ordine negli accessi significa rendere più comodo l'ingresso a chi entrerà.
«Poi tanto si torna indietro.» Si torna indietro, ma raramente al prezzo che si immaginava. Dopo due anni i dati sono cresciuti, si sono aggiunte integrazioni, il formato di alcuni servizi è proprietario e il costo di far uscire i dati non è trascurabile. La reversibilità va valutata prima, quando ancora si può scegliere, non quando è diventata un problema.
Perché quasi tutte le PMI finiscono ibride
Applicando le quattro domande a un'infrastruttura reale, il risultato tipico è un assetto misto, e non per compromesso ma per coerenza: posta e collaborazione in SaaS, dove i servizi sono maturi e gestirli in proprio non ha più senso; gestionale e archivi principali su server locali o dedicati, perché il carico è costante e l'accesso è quotidiano; backup e copia secondaria in cloud, perché la copia deve stare lontano da ciò che protegge; ambienti di test e progetti a termine su risorse a consumo, che si accendono e si spengono.
Questo assetto ha un difetto da conoscere: aumenta il numero di fronti da tenere sotto controllo. Più fornitori, più contratti, più credenziali, più punti in cui una configurazione può essere sbagliata. È esattamente la ragione per cui l'infrastruttura ibrida richiede un presidio di gestione dell'infrastruttura e una regia sui fornitori: la tecnologia si semplifica, il coordinamento no.
Come si conduce la decisione, in pratica
In una PMI non serve un progetto di sei mesi. Serve un percorso ordinato che si può percorrere in poche settimane, anche a mandato parziale.
Si parte da un inventario onesto: quali sistemi esistono, chi li usa, quanto sono critici, su che hardware girano, quando scade il supporto. Già questo passaggio, nella maggior parte dei casi, fa emergere due o tre sorprese — una macchina fuori supporto da anni, un applicativo che nessuno sa più chi mantiene.
Per ciascun sistema si applicano le quattro domande e si annota la risposta con la motivazione: serve a rendere la scelta rileggibile fra un anno, quando qualcuno chiederà perché si è fatto così. Sui sistemi dove la scelta non è ovvia, si costruisce il confronto economico su cinque anni con tutte le voci, comprese quelle sopra.
Poi si definisce una sequenza, non un big bang: si parte da ciò che ha meno dipendenze e più beneficio immediato, si verifica il risultato, si passa al successivo. Ogni spostamento deve avere criteri di accettazione — prestazioni, backup funzionante, accessi corretti, procedura di ritorno — e qualcuno che li verifica prima di dichiarare chiusa la migrazione. Il tema del governo di questi passaggi è quello che presidio nel servizio dedicato a cloud, migrazioni e ciclo di vita.
Il punto
Cloud e on-premise non sono due partiti: sono due modi di collocare un sistema, ciascuno con una convenienza che dipende da durata, prevedibilità, vincoli e disponibilità di servizi pronti. Le aziende che decidono bene non sono quelle che scelgono la tecnologia giusta, ma quelle che si pongono le domande giuste per ogni pezzo della propria infrastruttura, mettono per iscritto le risposte e le rivedono quando le condizioni cambiano.
Se stai valutando una migrazione, un rinnovo hardware in scadenza o semplicemente vuoi capire se l'assetto attuale è ancora quello giusto, scrivimi: il primo passo utile è quasi sempre mettere in fila i sistemi e guardarli uno per uno.