Un server cloud può offrire maggiore flessibilità rispetto a un’infrastruttura fisica tradizionale, ma non rappresenta automaticamente la scelta migliore per ogni azienda. La decisione dipende dai carichi di lavoro, dalle applicazioni utilizzate, dai requisiti di continuità, dalla connettività e dal modello economico complessivo.
Nelle infrastrutture con esigenze variabili, la pianificazione periodica della capacità e il controllo delle risorse aiutano a verificare se CPU, memoria, storage e rete siano dimensionati in modo coerente con i carichi effettivi. Il cloud permette di modificare più facilmente alcune di queste risorse senza dover intervenire direttamente sull’hardware fisico, ma richiede comunque progettazione e gestione.
Cos’è un server cloud aziendale
Secondo la definizione NIST SP 800-145, il cloud computing consente l’accesso on-demand a un insieme condiviso di risorse informatiche configurabili, che possono essere allocate e rilasciate rapidamente.
Nel modello Infrastructure-as-a-Service (IaaS), un server cloud è generalmente una macchina virtuale ospitata sull’infrastruttura di un Cloud Service Provider. Il provider gestisce i livelli fisici e di virtualizzazione previsti dal servizio; sistema operativo guest, applicazioni, dati e configurazioni rimangono invece sotto la responsabilità del cliente o del partner tecnologico incaricato, secondo il perimetro contrattuale.
La virtualizzazione separa logicamente i workload dall’hardware sottostante. Negli ambienti multi-tenant più clienti possono utilizzare la stessa infrastruttura fisica, mantenendo ambienti logicamente separati; altri servizi prevedono invece risorse dedicate. Il livello effettivo di isolamento dipende dalla tecnologia, dall’architettura e dal servizio acquistato.
Rispetto a un’infrastruttura on-premise, il cloud trasferisce al provider la gestione dell’hardware fisico sottostante. L’azienda non deve quindi presidiare direttamente server, alimentazione, componenti fisici e livello di virtualizzazione, pur continuando a gestire — direttamente o tramite un partner — tutto ciò che ricade nel proprio perimetro operativo.
Quando può avere senso valutare il cloud
La migrazione al cloud non dovrebbe partire dal presupposto che “cloud è sempre meglio”. È più corretto partire dai requisiti.
Tra gli scenari in cui un server cloud può essere particolarmente interessante rientrano:
- Carichi di lavoro variabili, con picchi periodici o stagionali che renderebbero inefficiente un dimensionamento hardware fisso.
- Rinnovo di infrastrutture a fine ciclo di vita, quando un server on-premise deve comunque essere sostituito.
- Accesso da più sedi o utenti distribuiti, quando applicazioni e dati devono essere raggiunti da località differenti.
- Ambienti di test, staging o sviluppo, che possono richiedere risorse solo per periodi limitati.
- Architetture ibride, nelle quali alcune risorse rimangono locali e altre vengono spostate nel cloud.
Sul piano economico, il cloud può spostare una parte degli investimenti iniziali in hardware verso costi operativi legati ai servizi utilizzati. Questo non significa necessariamente spendere meno: il risultato dipende da dimensionamento, licenze, modello di consumo e servizi gestiti.
Per un confronto più specifico tra le due alternative è utile approfondire cloud e server dedicato dal punto di vista dei costi, del modello di consumo e del TCO.
Responsabilità condivisa: cosa gestisce il provider e cosa resta al cliente
Uno degli aspetti più importanti di un’infrastruttura cloud è il modello di responsabilità condivisa.
Non esiste però una ripartizione identica per tutti i provider e per tutti i servizi. Le responsabilità effettive dipendono dal modello utilizzato, dalle funzionalità acquistate, dalla configurazione e dalle condizioni contrattuali.
In un servizio IaaS, il provider gestisce normalmente:
- infrastrutture fisiche e data center;
- hardware di calcolo, storage e rete sottostante;
- livello di virtualizzazione;
- componenti host previsti dal servizio.
L’azienda cliente mantiene invece normalmente la responsabilità degli elementi posti a suo carico, ad esempio:
- sistema operativo guest;
- identità e credenziali;
- configurazioni applicative;
- dati;
- controlli di sicurezza configurabili dal cliente.
Quando un server o una macchina virtuale cloud rientra nel perimetro gestito da Flanker, Flanker può occuparsi dell’installazione e configurazione del sistema operativo guest e della gestione degli aggiornamenti e delle patch di sicurezza, secondo quanto concordato con il cliente.
Altre attività — come firewall virtuali, routing, identità, cifratura, replica e backup — devono invece essere valutate in funzione dell’architettura adottata e dello specifico perimetro di servizio.
È quindi importante non fermarsi al nome del servizio cloud: prima della migrazione occorre definire con precisione chi gestisce cosa.
Governance e monitoraggio
Una VM nel cloud non diventa automaticamente efficiente solo perché può essere ridimensionata rapidamente.
Le metriche di utilizzo di CPU, memoria, storage e I/O aiutano a capire se le risorse allocate siano adeguate. Il cosiddetto rightsizing consiste proprio nel correggere nel tempo il dimensionamento dell’istanza sulla base del comportamento reale del workload.
Questa analisi deve però considerare anche:
- picchi di utilizzo;
- dipendenze applicative;
- requisiti di continuità;
- vincoli di licenza;
- architettura complessiva;
- costi associati alle diverse configurazioni.
Ridurre una VM sulla base della sola media CPU, per esempio, può essere una scelta sbagliata se il sistema deve assorbire picchi improvvisi o gestire processi critici.
Vendor lock-in: ridurre le dipendenze, non immaginare di eliminarle
Il vendor lock-in è la dipendenza tecnica o economica da uno specifico provider, servizio o tecnologia.
AgID richiama la portabilità e la riduzione delle dipendenze proprietarie tra gli aspetti da considerare nella progettazione cloud. Questo non significa che il lock-in possa essere eliminato completamente: spesso può soltanto essere mitigato.
Alcune scelte progettuali possono aiutare:
- preferire tecnologie e formati interoperabili quando possibile;
- utilizzare container quando migliorano realmente la portabilità applicativa;
- limitare, dove opportuno, dipendenze non necessarie da API proprietarie;
- mantenere procedure documentate per l’esportazione dei dati;
- distinguere chiaramente dati, database, immagini disco, configurazioni e dipendenze applicative.
La containerizzazione, per esempio, può ridurre alcune dipendenze dall’ambiente di esecuzione, ma non elimina automaticamente quelle legate a database gestiti, identità, storage, networking o API specifiche del provider.
La portabilità deve quindi essere progettata e verificata, non semplicemente presunta.
Come valutare un server cloud prima della migrazione
Prima di spostare un workload in cloud conviene rispondere almeno a queste domande:
- Quali applicazioni e dati devono essere migrati?
- Quali prestazioni sono realmente necessarie?
- Quali sono i picchi di utilizzo?
- Chi gestirà sistema operativo, patching e sicurezza?
- Come verranno gestiti backup e ripristino?
- Quali dipendenze esistono da altri sistemi?
- Quanto costa realmente l’ambiente nel suo complesso?
- Quanto sarebbe complesso spostarlo in futuro verso un’altra piattaforma?
Il cloud è uno strumento infrastrutturale, non un obiettivo in sé. La scelta corretta nasce dal confronto tra requisiti tecnici, responsabilità operative, continuità e sostenibilità economica.
Per questo Flanker affronta la progettazione cloud partendo dall’analisi dell’infrastruttura e dal perimetro di gestione richiesto, integrando quando necessario risorse cloud, sistemi locali e servizi di Managed IT & Infrastructure.
