La prima domanda non è "cloud o server in azienda?". È: quanto costa alla tua azienda se domani quel software non funziona? Una guida pratica per scegliere l’infrastruttura giusta partendo da continuità operativa, dati, costi e competenze — non dalla tecnologia in sé.
Quando un’azienda deve decidere dove far girare il proprio software, la domanda che si pone per prima è quasi sempre la stessa: cloud o server in azienda? È la domanda sbagliata, o meglio: è la seconda domanda. La prima è quanto costa restare fermi anche solo per qualche ora, e quanto di quel rischio l’azienda è disposta a sostenere. La scelta tecnica — cloud, on-premises o ibrido — viene dopo aver risposto a questo, insieme a natura e dimensione dei dati, competenze IT disponibili, infrastruttura già in uso, costo totale di possesso e responsabilità operativa.
La domanda da fare prima: quanto costa stare fermi?
Un fermo non è mai solo “il sito è giù”. Sono operatori che non possono lavorare, ordini che non vengono evasi, un servizio che smette di essere erogato ai clienti, transazioni che si perdono nel momento in cui avvengono. Prima ancora di parlare di infrastruttura, vale la pena elencare cosa succede davvero in azienda nelle prime ore di fermo.
- Operatori interni fermi, senza un processo alternativo per continuare a lavorare
- Ordini o richieste dei clienti che restano bloccati fino al ripristino
- Un servizio erogato a terzi che si interrompe, con effetti diretti sui clienti finali
- Transazioni, prenotazioni o inserimenti che avvengono nel momento esatto del fermo e rischiano di andare persi
- L’eventuale possibilità — o impossibilità — di un fallback manuale temporaneo, mentre il sistema è offline
La business continuity ha un costo. Ma anche l’assenza di business continuity ha un costo — semplicemente lo si paga solo quando succede, non prima.
Che dati deve gestire il sistema?
La scelta dell’infrastruttura dipende anche da cosa contiene il sistema, non solo da quanto deve restare acceso. Dati personali o strategici possono avere requisiti normativi specifici su dove e come vengono trattati e conservati; il volume complessivo e la dimensione dei singoli file incidono su storage e banda; la frequenza di accesso e la localizzazione delle sedi influenzano la latenza percepita da chi lavora sul sistema ogni giorno.
Un caso concreto: applicazioni che gestiscono file molto pesanti — disegni CAD, ortofoto, immagini o video ad alta risoluzione — possono rendere più razionale uno storage locale ad alte prestazioni, anche quando l’applicazione stessa gira in cloud. Non è una contraddizione: è la scelta giusta per quel tipo di dato.
Cloud non significa necessariamente AWS
“Cloud” è una categoria ampia, non un fornitore. Comprende hyperscaler come AWS, Google Cloud e Microsoft Azure, provider nazionali ed europei, e soluzioni VPS/cloud più economiche, con livelli di servizio (SLA) diversi tra loro.
Nella nostra esperienza, AWS è spesso la scelta più equilibrata per esperienza operativa maturata, elasticità delle risorse, ampiezza dei servizi disponibili e facilità di gestione — non perché sia sempre l’opzione più economica. Il fornitore giusto dipende dal progetto, non è una scelta valida a priori.
Perché Yayamedia tende a preferire il cloud per le PMI
Per la maggior parte dei progetti che sviluppiamo per PMI, il cloud riduce l’infrastruttura interna da gestire, permette provisioning e resize delle risorse in tempi rapidi, abbassa il carico operativo quotidiano e mette a disposizione servizi infrastrutturali — backup gestiti, replica, ridondanza — che sarebbe costoso ricreare da soli. Per questo il 90% dei progetti che sviluppiamo oggi gira su infrastruttura AWS, dimensionata sulle esigenze reali del cliente: postazioni, utenti, traffico previsto, volume degli archivi.
Dopo oltre vent’anni di esperienza nella gestione di server, il cloud è normalmente la soluzione che ci fa dormire più tranquilli. Ma non è sempre la soluzione corretta: dipende dal problema che il software deve risolvere, non da una preferenza ideologica.
Infrastruttura cloud AWS con crittografia end-to-end e autenticazione a più fattori, per dati riservati di centinaia di farmacie clienti.
Quando l’on-premises ha senso
- Hai già un’infrastruttura interna evoluta e personale IT che la presidia
- Gestisci grandi moli di dati che devono restare fisicamente vicine a chi le usa
- Hai requisiti specifici — normativi, contrattuali o di sicurezza — che richiedono il controllo diretto dell’hardware
- Il servizio tollera un downtime più ampio di quello che il cloud giustificherebbe economicamente
- Hai già investimenti hardware recenti che non ha senso abbandonare
On-premises non significa obsoleto. Cloud non significa automaticamente moderno. Sono due modi diversi di rispondere allo stesso problema, e in alcuni contesti quello meno di moda è anche quello più corretto.
Un’architettura web on-premise scelta per varchi fisici e dispositivi fissi, dove il controllo diretto dell’hardware ha più senso del cloud.
Architetture ibride
Molti progetti reali non sono puramente cloud o puramente on-premises: un’applicazione che gira in cloud ma si appoggia a uno storage locale per i file più pesanti; dati replicati tra due sedi fisiche per garantire continuità; un backup mantenuto in una posizione geografica diversa da quella principale; servizi esterni richiamati via API indipendentemente da dove gira il resto del sistema.
L’architettura ibrida non è un compromesso al ribasso: è spesso la scelta più razionale quando esigenze diverse — prestazioni, prossimità dei dati, continuità, costo — non sono tutte soddisfatte al meglio dalla stessa opzione.
Dove gira e chi lo gestisce sono due decisioni
Un errore comune è pensare che “cloud” o “on-premises” risolva anche la domanda su chi si occupa della gestione quotidiana. Sono due assi separati:
| Dove gira | Chi gestisce | Cosa significa in pratica |
|---|---|---|
| Cloud | Yayamedia | Infrastruttura AWS dimensionata sul progetto, con monitoraggio, patch e continuità a nostro carico. |
| Cloud | IT del cliente | Il cliente mantiene account e gestione dell’infrastruttura cloud; noi restiamo responsabili dello stack applicativo. |
| On-premises | Yayamedia (stack applicativo) | Il server è del cliente, ma applicazione, aggiornamenti e continuità applicativa restano a nostro carico. |
| On-premises | IT del cliente | Il cliente gestisce hardware e sistemistica; noi ci occupiamo dello sviluppo e dell’evoluzione del software. |
| Ibrido | Responsabilità condivise | Ogni componente ha un responsabile definito — nessuna zona grigia su chi interviene in caso di problema. |
Scalabilità senza overengineering
La scalabilità si progetta prima di tutto nel software, non si compra con più CPU o più RAM. Il cloud facilita l’adeguamento delle risorse, ma un’architettura mal progettata resta lenta anche su un server enorme. La crescita, quando serve davvero, segue in genere una progressione:
Risorse condivise
Si parte da un’infrastruttura condivisa, adeguata al volume iniziale di utenti e traffico.
Risorse dedicate
Quando il carico cresce, si passa a risorse dedicate al solo progetto, eliminando la contesa con altri carichi.
Resize verticale
Si aumentano CPU e memoria della stessa istanza: la via più rapida per assorbire una crescita moderata.
Database separato
Il database viene spostato su un’istanza dedicata, così applicazione e dati non competono più per le stesse risorse.
Più application server
Si distribuisce il carico applicativo su più server, con un bilanciatore davanti a smistare il traffico.
Replica e failover
Si introducono repliche del database e failover automatico, per assorbire sia il carico sia i guasti hardware.
Ogni passaggio ha un costo, e non tutti i progetti devono percorrerli tutti. Il nostro focus sono applicazioni business e gestionali per PMI, non piattaforme real-time con milioni di utenti simultanei: la scalabilità che serve davvero è quella misurata sul problema reale, non quella immaginata a tavolino.
Vendor lock-in
Progettiamo lo stack applicativo — Java/ColdFusion su Linux, con interfacce web — per restare portabile: lo stesso software può essere distribuito su infrastrutture diverse, usa protocolli standard e, dove ha senso, storage S3-compatible invece di API proprietarie non sostituibili. I singoli componenti infrastrutturali restano intercambiabili.
Non promettiamo “zero lock-in”: nessuna scelta infrastrutturale è mai completamente neutra. Ma la portabilità è un criterio di progettazione fin dall’inizio, non un ripensamento successivo.
Quanto costa davvero l’on-premises?
Comprare un server è solo il primo passo. Alla spesa iniziale si aggiungono storage, ridondanza, UPS, spazio in rack o locali climatizzati, connettività dedicata, backup esterno, monitoraggio, patch di sicurezza, il tempo delle persone che se ne occupano — anche fuori orario — e il rinnovo dell’hardware quando diventa obsoleto.
Il server fisico è il primo costo, non l’ultimo.
Tutte le voci di costo, dall’hardware al personale, con la formula concettuale del TCO.
Backup, disaster recovery e business continuity
Sono tre cose diverse, spesso confuse tra loro: il backup è la copia dei dati, il disaster recovery è la capacità di ripartire dopo un guasto grave, la business continuity è la capacità dell’azienda di continuare a operare — anche in modo ridotto — mentre il sistema principale è fermo. Due indicatori aiutano a misurarle in modo concreto: l’RPO, quanti dati puoi permetterti di perdere, e l’RTO, quanto tempo puoi restare fermo prima che il danno diventi inaccettabile.
RPO, RTO e i livelli di resilienza possibili, dal backup giornaliero alla ridondanza geografica.
Il percorso decisionale, passo per passo
Le domande da porsi, in ordine, per capire quale infrastruttura si adatta meglio al tuo caso — non un test con un risultato automatico, ma una traccia per la discussione:
L’output di questo percorso è cloud, on-premises, ibrido — oppure, più spesso di quanto si pensi, la constatazione che serve un approfondimento con chi conosce davvero il tuo processo prima di decidere. Non è un test con un risultato automatico: usalo come traccia per la discussione con il tuo team o con noi.
La scelta giusta non è quella con più tecnologia
La scelta corretta non è quella con più tecnologia, ma quella che protegge il processo aziendale al livello di rischio e di costo che l’azienda può realisticamente sostenere. Yayamedia non vende semplicemente lo sviluppo iniziale di un software: prende in carico sistemi che diventano parte dell’operatività dell’azienda e li accompagna nel tempo — applicazione, infrastruttura, integrazioni, sicurezza ed evoluzione. La tecnologia si sceglie dopo aver capito il processo, il rischio e il costo del problema.
Longevità, sicurezza e portabilità: i criteri che guidano ogni scelta infrastrutturale, non solo cloud/on-premises.
La stessa logica di rischio e costo si applica a un sistema esistente che funziona ma inizia a starti stretto.
Domande frequenti
- Conviene sempre il cloud per una PMI?
- No. Tendiamo a preferirlo perché per la maggior parte dei progetti riduce l’infrastruttura da gestire e il carico operativo, ma la scelta dipende dai dati trattati, dalle competenze disponibili e dai requisiti specifici del progetto — non è una preferenza ideologica.
- AWS è sempre la soluzione più economica?
- No. AWS è spesso la scelta più equilibrata per esperienza operativa, elasticità e ampiezza dei servizi, ma esistono provider nazionali, europei e soluzioni VPS più economiche con livelli di servizio diversi. Il fornitore giusto dipende dal progetto.
- Se scegliamo on-premises, dobbiamo gestire tutto da soli?
- No. Puoi mantenere l’hardware internamente mentre restiamo responsabili dello sviluppo e dell’evoluzione dell’applicazione, oppure definire una responsabilità condivisa: la gestione tecnica e quella applicativa sono due decisioni separate.
- È possibile cambiare infrastruttura in futuro senza ripartire da zero?
- È uno degli obiettivi con cui progettiamo lo stack: componenti portabili, protocolli standard e, dove ha senso, storage compatibile S3. Non promettiamo zero lock-in, ma la reversibilità è un criterio fin dall’inizio, non un ripensamento.