Cloud Strategy - Parte I: Capire il Cloud

L’adozione del cloud non è solo una migrazione tecnica, ma un cambiamento nel modo in cui l’IT viene consumata, finanziata, protetta e gestita. Questo articolo spiega come il cloud trasformi procurement, costi, operations, sicurezza, governance e responsabilità, richiedendo automazione, FinOps, servizi gestiti e un nuovo modello operativo orientato al miglioramento continuo.

Questa serie offre una sintesi con annotazioni del libro di Gregor Hohpe, Cloud Strategy, disponibile su leanpub.com/cloudstrategy.

Executive Summary

L’adozione del cloud non è semplicemente una migrazione dall’infrastruttura on-premises ai data center di un provider. È un cambiamento più ampio e complesso nel modo in cui l’IT viene consumata, finanziata, protetta, governata e gestita. L’IT tradizionale on-premises è costruita intorno al concetto di proprietà: le organizzazioni acquisiscono asset fisici, pianificano la capacità in anticipo, gestiscono stack hardware e software e operano tramite cicli di procurement, processi manuali e impegni di lungo periodo. Il modello cloud cambia questa logica offrendo infrastruttura, piattaforme, dati, sicurezza e capacità di analytics come servizi on-demand.

Questa transizione sposta l’IT da un modello fortemente basato su CapEx, fondato su investimenti iniziali e ammortamento, verso un modello OpEx più flessibile basato sul consumo misurato. Tuttavia, il cloud non riduce automaticamente i costi. I risparmi devono essere conquistati attraverso architettura, automazione, visibilità dei costi, elasticità, servizi gestiti e pratiche FinOps disciplinate.

Dal punto di vista operativo, il cloud sostituisce la pianificazione statica con l’elasticità dinamica, il provisioning manuale con il self-service e la configurazione tramite ticket con Infrastructure as Code e operazioni orientate all’automazione. Questo abilita delivery più rapida, sperimentazione, resilienza e portata globale, ma richiede anche governance più solida, gestione delle identità, responsabilità sui costi e disciplina di sicurezza.

Sicurezza e compliance cambiano anch’esse in modo significativo. Nel cloud pubblico, le organizzazioni non controllano più direttamente l’infrastruttura fisica. Si affidano invece a isolamento logico, cifratura, identity and access management, policy, logging, monitoraggio e guardrail automatizzati. Il modello di responsabilità condivisa diventa centrale: il provider protegge la piattaforma cloud sottostante, mentre il cliente rimane responsabile di workload, dati, identità, configurazioni e utilizzo dei servizi.

Il messaggio strategico principale è che il cloud non dovrebbe essere trattato come un semplice contratto di outsourcing IT o come una forma di hosting più economica. È un nuovo modello operativo. Le organizzazioni che traggono maggior beneficio dal cloud sono quelle che ripensano procurement, operations, architettura, governance, sicurezza e gestione finanziaria intorno a velocità, automazione, consumo di servizi e miglioramento continuo.

Cloud Computing: fare chiarezza

Il panorama cloud soffre spesso di terminologia confusa, abbreviazioni e frasi alla moda. Per stabilire una base chiara, chiariamo questi concetti.

La definizione ufficiale più citata proviene da NIST SP 800-145, The NIST Definition of Cloud Computing:

Il cloud computing è un modello che consente un accesso di rete ubiquo, comodo e on-demand a un pool condiviso di risorse di calcolo configurabili (ad esempio reti, server, storage, applicazioni e servizi), che possono essere rapidamente fornite e rilasciate con uno sforzo minimo di gestione o interazione con il provider del servizio. Questo modello cloud è composto da cinque caratteristiche essenziali, tre modelli di servizio e quattro modelli di deployment.

NIST, acronimo di National Institute of Standards and Technology (un ente federale statunitense), identifica cinque pilastri fondamentali del modello cloud:

• Self-service on-demand: un consumatore può effettuare autonomamente il provisioning di capacità di calcolo, come tempo server e storage di rete, quando necessario e in modo automatico, senza richiedere interazione umana con ciascun provider.
• Accesso di rete: le capacità sono disponibili tramite rete e accessibili attraverso meccanismi standard che ne promuovono l’uso da piattaforme client eterogenee, leggere o pesanti (ad esempio telefoni cellulari, tablet, laptop e workstation).
• Pooling delle risorse: le risorse di calcolo del provider sono messe in comune per servire più consumatori tramite un modello multi-tenant, con risorse fisiche e virtuali diverse assegnate e riassegnate dinamicamente in base alla domanda. Esiste un senso di indipendenza dalla localizzazione: il cliente generalmente non controlla né conosce la posizione esatta delle risorse fornite, ma può specificare la localizzazione a un livello di astrazione più alto (ad esempio paese, regione o data center).
• Elasticità rapida: le capacità possono essere fornite e rilasciate elasticamente, in alcuni casi automaticamente, per scalare rapidamente verso l’esterno e verso l’interno in base alla domanda. Per il consumatore, le capacità disponibili per il provisioning spesso appaiono illimitate e utilizzabili in qualsiasi quantità in qualsiasi momento.
• Servizio controllato: i sistemi cloud controllano e ottimizzano automaticamente l’uso delle risorse sfruttando capacità di misurazione a un livello di astrazione appropriato al tipo di servizio (ad esempio storage, elaborazione, banda e account utente attivi). L’uso delle risorse può essere monitorato, controllato e riportato, fornendo trasparenza sia al provider sia al consumatore del servizio utilizzato.

NIST definisce anche tre modelli di servizio (SaaS, PaaS e IaaS) e quattro modelli di deployment (private cloud, community cloud, public cloud e hybrid cloud).

Modelli di servizio: SaaS, PaaS, IaaS

I modelli di servizio cloud sono di fatto una gerarchia di responsabilità condivisa. Man mano che ci si sposta verso l’alto nello stack, il provider cloud assume una maggiore gestione dell’infrastruttura sottostante.

IaaS: Infrastructure as a Service

Con IaaS il provider cloud offre risorse di calcolo e building block di basso livello: server, storage, rete, load balancer e così via. Anche se non acquisti server fisici, stai comunque gestendo lo stack software, ad esempio installare Linux su una macchina virtuale EC2, distribuire l’applicazione, applicare patch al sistema operativo, gestire i backup.

Utile per: flessibilità, migrazioni, architetture personalizzate, workload legacy.
Compromesso: devi comunque gestire molte attività operative.

PaaS: Platform as a Service

Con PaaS, distribuisci codice o container, mentre la piattaforma gestisce runtime, scaling, patching, load balancing e gestione dell’infrastruttura. Ad esempio: Azure App Service, Google App Engine, Elastic Beanstalk.

Utile per: delivery applicativa più rapida, minore carico operativo, workload web/API standard.
Compromesso: meno controllo di basso livello e maggiore dipendenza dal modello di piattaforma del provider.

SaaS: Software as a Service

Con SaaS, accedi a un’applicazione completa tramite rete. Non gestisci server, sistemi operativi, database, runtime o codice applicativo. Ad esempio, Amazon Connect e QuickSight. AWS è conosciuta soprattutto come provider di infrastruttura e piattaforma cloud, anche se offre anche alcune applicazioni assimilabili al SaaS.

Utile per: capacità di business standard in cui costruire o gestire software proprio aggiunge poca differenziazione.
Compromesso: personalizzazione limitata rispetto alla costruzione di una propria applicazione.

Modelli di deployment: private, community, public, hybrid

I modelli di deployment descrivono per chi è il cloud e come viene reso disponibile.

Private cloud

Un private cloud è dedicato a una sola organizzazione. Può essere eseguito nel data center dell’azienda o ospitato da una terza parte, ma non è condiviso con clienti non correlati.

Nota importante: un private cloud non è semplicemente “virtualizzazione”. Per essere un vero cloud, dovrebbe comunque fornire le caratteristiche del cloud: self-service, pooling delle risorse, elasticità, misurazione dell’uso e automazione.

Ad esempio, provider europei come OVHcloud, Aruba Cloud e IONOS possono offrire alternative al public cloud hyperscale o opzioni cloud dedicate/ospitate, a seconda del servizio.

Community cloud

Un community cloud è condiviso da più organizzazioni con esigenze comuni, come compliance, sicurezza, giurisdizione o missione. Esempio: diverse agenzie governative che condividono una piattaforma cloud progettata intorno ai requisiti del settore pubblico.

Questo modello è discusso meno spesso rispetto a public, private e hybrid cloud, ma fa parte della definizione NIST. Esempi adiacenti includono region cloud governative come AWS GovCloud e Azure Government, e federazioni cloud per la ricerca come European Open Science Cloud.

Public cloud

Un public cloud è gestito per un uso ampio da parte di molti clienti. L’infrastruttura è posseduta e gestita da un cloud provider, e i clienti consumano servizi tramite rete. Esempi includono AWS, Microsoft Azure, Google Cloud, Oracle Cloud e Alibaba Cloud.

Da qui in avanti, con “Cloud” intenderò solo il Public Cloud, come AWS, Azure e Google Cloud. Inoltre, il focus principale per i dettagli tecnici sarà AWS, che è la piattaforma cloud che conosco meglio.

Quote di mercato

Questi dati provengono dal breakdown Synergy/CRN per il Q3 2025:

Hybrid cloud

Un hybrid cloud combina due o più ambienti cloud distinti, come private cloud più public cloud, oppure più cloud connessi tra loro in un’architettura coordinata.

Esempio: un’azienda mantiene alcuni sistemi sensibili in un private cloud o in un ambiente on-premises mentre esegue applicazioni rivolte ai clienti in AWS o Azure.

Un punto chiave: hybrid cloud non significa semplicemente “abbiamo alcuni server on-premises e alcuni in AWS”. Deve esistere una qualche forma di integrazione, come identità, networking, flussi dati, governance, monitoraggio o portabilità dei workload.

On-premises e cloud

Panoramica

La tabella seguente offre una panoramica delle principali differenze tra on-premises (data center) e cloud.

Proprietà dell’infrastruttura contro consumo di servizi

In una configurazione on-premises tradizionale, un’organizzazione in genere gestisce l’intero insieme dei propri asset fisici . Questo include l’affitto o la proprietà di strutture data center, server, apparati di rete, array di storage e firewall, insieme ai relativi sistemi di alimentazione, raffreddamento e sicurezza. Il procurement in questo modello di solito comporta un ciclo di selezione del prodotto, negoziazione contrattuale e integrazione nei flussi operativi esistenti.

Uno svantaggio significativo di questo approccio è la dipendenza da licenze costose e di lungo periodo, che spesso portano a un forte vendor lock-in.

Il modello cloud sposta questo paradigma verso il consumo di infrastruttura e piattaforme come servizi . Invece dello sforzo manuale di installare e mantenere hardware fisico, i team utilizzano API, framework di automazione e cataloghi di servizi per effettuare il provisioning di risorse come compute, storage e database.

Questo cambiamento rappresenta più di un semplice cambio di collocazione; è una trasformazione fondamentale del modo in cui l’IT viene consumata. Il cloud funge da piattaforma completa per dati, analytics e sicurezza, richiedendo alle organizzazioni di andare oltre l’idea del cloud come semplice progetto IT. Abbracciare il cloud richiede un “lifestyle change”, un cambiamento di stile operativo, in cui i processi di procurement e operations vengono completamente rivalutati. Questo principio è spesso ignorato o sottovalutato dai business leader, con conseguenze significative: migrazioni più lente, costi più elevati, governance più debole e opportunità mancate di catturare il vero valore dell’adozione cloud.

On-premises: focus sull’acquisizione e gestione di asset fisici.

Cloud: focus sul consumo di capacità come servizi on-demand.

CapEx contro OpEx

La transizione al cloud computing introduce un cambiamento fondamentale nel modo in cui l’IT viene finanziata. In un ambiente tradizionale on-premises, le organizzazioni si basano tipicamente su spese in conto capitale (CapEx), dove la capacità viene acquistata in anticipo sulla base di previsioni di domanda di lungo periodo. Questa infrastruttura viene poi trattata come asset fisico e ammortizzata nel suo ciclo di vita.

Al contrario, il cloud opera principalmente secondo un modello di spesa operativa (OpEx). Qui, i servizi vengono consumati secondo necessità, con costi legati a metriche granulari come utilizzo orario, volume di storage o numero di transazioni . Sebbene questo approccio pay-as-you-go modifichi la logica finanziaria dell’IT, non garantisce risparmi immediati. Secondo Gregor Hohpe in Cloud Strategy, i risparmi del cloud devono essere “earned”, cioè guadagnati, attraverso un’attenta gestione dei costi, automazione e uso di architetture elastiche.

• Capital Expenditure (CapEx): allineato all’IT on-premises, comporta costi iniziali significativi per hardware e licenze perpetue, ammortizzati nel tempo a bilancio.
• Operational Expenditure (OpEx): allineato al modello cloud, comporta costi variabili per il consumo continuativo dei servizi. Queste spese sono normalmente dedotte dal reddito imponibile nel periodo in cui vengono sostenute.

On-premises: i modelli favoriscono grandi investimenti iniziali e lunghi cicli di ammortamento.

Cloud: i modelli privilegiano fatturazione basata sull’uso e scalabilità dinamica.

Pianificazione statica contro elasticità dinamica

Le configurazioni tradizionali on-premises si basano su una rigorosa pianificazione della capacità. Questo processo di previsione comporta intrinsecamente il rischio di sotto-provisioning, che causa interruzioni del servizio, o di over-provisioning, che porta a capitale sprecato in hardware sottoutilizzato.

Il cloud computing affronta queste sfide tramite l’elasticità, consentendo provisioning e rilascio delle risorse quasi istantanei. Questa flessibilità è essenziale per prodotti digitali con domanda variabile, inclusi job batch intensivi o picchi stagionali nel retail. Tuttavia, realizzare pienamente il potenziale dell’elasticità richiede un’architettura applicativa e un modello operativo capaci di scalare autonomamente.

On-premises: cicli che si estendono per mesi o anni

Cloud: consente di scalare dinamicamente la capacità per soddisfare i requisiti in tempo reale.

Processo di procurement contro self-service

Il procurement infrastrutturale tradizionale può includere budget, ordini di acquisto, negoziazioni con fornitori, tempi di consegna, installazione, configurazione e approvazioni. Il provisioning di un server può richiedere settimane o mesi.

Il cloud introduce il self-service on-demand. I team possono effettuare direttamente il provisioning di risorse approvate, spesso in minuti o secondi, senza attendere acquisto hardware o installazione manuale.

Questa è una delle differenze più importanti per l’agilità del business. Il valore non è solo che l’infrastruttura appare più velocemente; il valore è che i team possono sperimentare, testare, distribuire e imparare più velocemente.

On-premises: richiedere, approvare, acquistare, installare, configurare.
Cloud: effettuare provisioning tramite self-service e automazione.

Configurazione manuale contro Infrastructure as Code

Negli ambienti tradizionali, l’infrastruttura è spesso configurata manualmente dai team operations e documentata tramite ticket, fogli di calcolo, diagrammi e runbook. L’automazione è certamente possibile con strumenti come Chef, Puppet o Ansible, ma è tipicamente stratificata sopra l’ambiente invece di essere profondamente integrata nella piattaforma stessa.

Nel cloud, al contrario, l’infrastruttura è esposta tramite API fin dall’inizio, rendendo automazione e Infrastructure as Code una parte più naturale del modello operativo: l’infrastruttura può essere descritta come codice . Reti, subnet, regole firewall, ruoli IAM, database, istanze compute, cluster Kubernetes, allarmi di monitoraggio e bucket storage possono essere definiti in template e distribuiti automaticamente.

Infrastructure as Code cambia la natura delle operations, rendendo l’infrastruttura ripetibile, versionata, soggetta a peer review, riutilizzabile, auditabile e più facile da ricreare dopo un guasto.

On-premises: infrastruttura spesso gestita tramite processi manuali e change ticket.
Cloud: infrastruttura sempre più gestita tramite codice, pipeline e automazione delle policy.

Ambienti statici contro ambienti disposable

In molti ambienti on-premises, i server sono trattati come asset longevi. Hanno un nome, vengono mantenuti, aggiornati, riparati e preservati per anni.

Nel pensiero cloud-native, l’infrastruttura dovrebbe essere più disposable. Se un server o un container fallisce, lo sostituisci. Se un ambiente viene corrotto, lo ricrei. Se un deployment fallisce, fai rollback o ridistribuisci. Questo cambia il mindset da “proteggere ogni server” a “progettare sistemi che sopravvivono al guasto dei componenti”.

On-premises: infrastruttura spesso trattata come preziosa e longeva.
Cloud: infrastruttura trattabile come sostituibile e disposable.

Visione centrata sull’hardware contro visione centrata sull’applicazione

Nell’IT tradizionale, le conversazioni iniziano spesso da server, storage, reti e data center.

Nel cloud, la domanda più utile è: di cosa ha bisogno l’applicazione? Hohpe sottolinea con forza questo punto: “nessuno vuole un server”. Il business vuole applicazioni, esperienze per i clienti, disponibilità, insight e velocità. Il server è solo un mezzo per raggiungere un fine.

On-premises: l’infrastruttura è spesso il punto di partenza.
Cloud: l’applicazione e il risultato di business dovrebbero essere il punto di partenza.

Servizi infrastrutturali contro servizi gestiti

In un ambiente on-premises, l’azienda di solito gestisce internamente gran parte dello stack: sistemi operativi, database, middleware, sistemi di backup, piattaforme di monitoraggio, message broker, data warehouse e strumenti di sicurezza.

Nel cloud, molte di queste capacità sono disponibili come servizi gestiti. Il provider gestisce l’infrastruttura sottostante e parte o gran parte del livello piattaforma.

I servizi gestiti sono uno dei maggiori elementi distintivi del cloud. Permettono ai team di concentrarsi meno sulla gestione di piattaforme commodity e più sulla creazione di valore di business. Il cloud è un ecosistema di servizi, non solo una piattaforma su cui eseguire applicazioni.

On-premises: gestisci più parti dello stack.
Cloud: il provider gestisce più parti dello stack.

Costo infrastrutturale fisso contro servizio misurato

Le piattaforme cloud forniscono una misurazione dettagliata della fatturazione. L’utilizzo può essere misurato per account, team, applicazione, ambiente, servizio, tag, region, periodo temporale o tipo di risorsa.

Questo abilita un livello di trasparenza finanziaria spesso difficile nell’IT tradizionale.

Questo crea la necessità del FinOps: la disciplina che collega team di engineering, finance e business per gestire continuamente valore e costi del cloud. In un data center, una volta acquistata l’infrastruttura, il costo marginale dello spreco può essere invisibile. Nel cloud, le risorse inutilizzate compaiono in fattura.

On-premises: il costo è spesso allocato tramite budget, ammortamenti e modelli interni di chargeback.
Cloud: il costo può essere misurato e attribuito con molta più granularità.

Data center locali contro presenza globale

Un data center enterprise tradizionale si trova di solito in un numero limitato di sedi fisiche. Espandersi globalmente richiede grandi investimenti, contratti, strutture, networking, attività di compliance e capacità operativa.

I grandi cloud provider offrono region globali, availability zone, reti edge e capacità di content delivery. Questo rende più semplice distribuire applicazioni più vicine agli utenti, progettare per la resilienza geografica, soddisfare alcuni requisiti di data residency e costruire disaster recovery tra region.

On-premises: l’espansione globale richiede nuove strutture o contratti di hosting.
Cloud: l’infrastruttura globale è già disponibile come capacità di piattaforma.

Ridondanza tramite capacità di riserva contro resilienza tramite design

La resilienza tradizionale dipende spesso da hardware ridondante: server di backup, data center secondari, storage duplicato e costosa capacità in standby.

Il cloud usa ancora la ridondanza, ma incoraggia anche la resilienza tramite architettura: più availability zone, sostituzione automatizzata, load balancing, autoscaling, database gestiti, deployment immutabili, code, retry e pattern multi-region.

La differenza è che la resilienza diventa più software-defined e guidata dall’architettura.

On-premises: la resilienza spesso dipende da infrastruttura ridondante acquistata in anticipo.
Cloud: la resilienza può essere progettata tramite servizi gestiti, automazione e architetture distribuite.

Sicurezza perimetrale contro sicurezza centrata sull’identità

Gli ambienti tradizionali si affidano spesso in modo forte alla sicurezza perimetrale di rete: firewall, segmentazione di rete, VPN e reti interne considerate fidate.

Gli ambienti cloud richiedono un modello più forte centrato sull’identità. Identity and access management diventa il nuovo control plane. Ogni utente, servizio, applicazione, workload e pipeline di automazione richiede permessi gestiti con attenzione.

On-premises: la sicurezza spesso parte dal perimetro di rete.
Cloud: la sicurezza parte da identità, policy, configurazione, cifratura e monitoraggio continuo.

Governance manuale contro guardrail e policy as code

La governance tradizionale dipende spesso da approvazioni prima che il lavoro possa procedere. Un team invia una richiesta, un comitato la esamina e un altro team la implementa.

Il cloud rende difficile questo modello perché le risorse possono essere create rapidamente e su larga scala. Il modello migliore è la governance automatizzata: definire cosa è consentito (ad esempio AWS Service Control Policies), prevenire configurazioni pericolose, rilevare violazioni e rimediare automaticamente.

On-premises: la governance spesso si basa sul controllo manuale.
Cloud: la governance dovrebbe basarsi su guardrail automatizzati.

Cicli di rilascio lenti contro pipeline di delivery più rapide

Il cloud è strettamente connesso alle pratiche moderne di software delivery.

Poiché l’infrastruttura può essere automatizzata, gli ambienti possono essere creati rapidamente e i servizi sono accessibili tramite API, i team possono costruire pipeline CI/CD che testano, distribuiscono e rilasciano software con maggiore frequenza. Si possono ottenere risultati simili anche on-premises, ma in generale l’ambiente cloud è più adatto a questo.

On-premises: i vincoli infrastrutturali spesso rallentano la delivery.
Cloud: la delivery può essere accelerata tramite automazione e servizi di piattaforma.

Operations centralizzate contro responsabilità condivisa

Il cloud non elimina la responsabilità operativa. Cambia chi è responsabile di cosa.

Il cloud provider è responsabile della sicurezza e dell’operatività della piattaforma cloud sottostante. Il cliente rimane responsabile di come i servizi vengono configurati e usati: identità, dati, applicazioni, policy di accesso, esposizione di rete, logging, compliance e architettura. Più il servizio è gestito, più il provider opera. Ma il cliente non diventa mai privo di responsabilità.

On-premises: l’azienda è responsabile di quasi tutto al di fuori del data center fisico.
Cloud: la responsabilità è condivisa tra provider e cliente.

Proprietà tecnologica contro pensiero prodotto/piattaforma

In un modello on-premises, i team infrastrutturali sono spesso organizzati intorno alle tecnologie: team server, team rete, team storage, team database, team sicurezza.

Il cloud incoraggia il pensiero prodotto e piattaforma. Un team cloud o platform centrale non dovrebbe semplicemente diventare un team infrastrutturale basato su ticket in un nuovo ambiente. Il suo compito dovrebbe essere fornire capacità riutilizzabili, paved roads, piattaforme self-service, template, guardrail di sicurezza, visibilità dei costi e abilitazione degli sviluppatori.

On-premises: i team spesso si allineano intorno a silos tecnici.
Cloud: i team si allineano sempre più intorno a piattaforme, prodotti e value stream end-to-end.

Ambienti fissi contro sperimentazione

Nell’IT tradizionale, creare un nuovo ambiente di test, con nuove tecnologie e strumenti, può essere costoso e lento. Questo scoraggia la sperimentazione.

Nel cloud, ambienti temporanei possono essere creati per sviluppo, test, proof of concept, formazione, analytics o campagne di breve durata. Quando non servono più, possono essere eliminati. Questo cambia il modo in cui i team innovano.

On-premises: la sperimentazione compete con capacità scarsa.
Cloud: la sperimentazione diventa più facile, economica e rapida quando governata correttamente.

Cicli lenti di refresh hardware contro evoluzione continua della piattaforma

On-premises, la tecnologia cambia attraverso cicli di refresh. L’hardware può essere sostituito ogni tre-cinque anni. Upgrade importanti della piattaforma possono essere pianificati con mesi di anticipo.

I cloud provider rilasciano continuamente nuovi servizi, tipi di istanza, region, capacità database, servizi AI, funzionalità di sicurezza e strumenti operativi. Questo crea un vantaggio ma anche una sfida: la cloud strategy non è mai finita. I team devono imparare continuamente e rivalutare cosa costruire, acquistare, consumare, sostituire o dismettere.

On-premises: l’innovazione segue cicli interni di refresh e upgrade.
Cloud: l’innovazione arriva continuamente dall’ecosistema del provider.

Pieno controllo contro meno controllo ma più leva

On-premises offre all’azienda controllo diretto sull’hardware, sulla localizzazione fisica, sugli apparati di rete, sui sistemi di storage e sulle scelte infrastrutturali di basso livello.

Il cloud riduce alcune forme di controllo. Non controlli i data center fisici del provider, il ciclo di vita dell’hardware, l’implementazione interna o la roadmap dei servizi. Ma il cloud aumenta la leva. Ottieni accesso a infrastruttura globale, servizi gestiti, API di automazione, capacità di sicurezza avanzate, piattaforme ad alta scala e innovazione che per la maggior parte delle aziende sarebbe irrealistico costruire da sole.

On-premises: più controllo diretto, più carico operativo.
Cloud: meno controllo fisico, più leva di piattaforma.

Disponibilità del data center contro architettura a livello di servizio

Negli ambienti tradizionali, la disponibilità è spesso discussa in termini di uptime del data center, ridondanza hardware e SLA infrastrutturali.

Nel cloud, la disponibilità applicativa dipende soprattutto da come l’architettura usa i servizi cloud. Eseguire un’applicazione su una sola macchina virtuale in una sola availability zone è molto diverso dal progettarla su più zone con database gestiti, load balancing, autoscaling e recovery automatizzata. Il cloud fornisce building block per l’alta disponibilità, ma l’architettura deve usarli correttamente.

Per essere precisi, la disponibilità applicativa nel cloud è influenzata anche dalla disponibilità dell’infrastruttura cloud stessa. Tutti i grandi player del cloud finiscono periodicamente nelle notizie per outage importanti che possono durare ore o persino giorni.

On-premises: la disponibilità spesso corrisponde alla ridondanza infrastrutturale.
Cloud: la disponibilità dipende dall’architettura dei servizi e dalla progettazione per il guasto.

Accesso alla rete interna contro accesso internet-native

I sistemi on-premises spesso presuppongono reti aziendali interne, connettività privata, VPN e confini enterprise fidati.

I servizi cloud sono progettati per un ampio accesso di rete tramite meccanismi standard. Questo non significa che tutto debba essere pubblico. Significa che i modelli di accesso sono di solito basati su API, consapevoli dell’identità, cifrati e progettati per utenti, applicazioni e servizi distribuiti.

On-premises: l’accesso spesso presuppone una rete aziendale.
Cloud: l’accesso è progettato per ambienti distribuiti e internet-scale.

Backup come infrastruttura contro backup come policy

In un ambiente on-premises, il backup spesso richiede sistemi dedicati, storage, schedulazioni, nastri o appliance, strumenti di replica e team operativi.

Nel cloud, il backup può spesso essere definito tramite policy di servizio: snapshot, versioning degli oggetti, lifecycle rule, cross-region replication, servizi di backup gestiti (ad esempio AWS Backup) e classi di storage di archivio. Questo non elimina la necessità di una strategia di backup, test di restore, progettazione della retention e compliance. Ma cambia il modello di implementazione.

On-premises: il backup è spesso una piattaforma infrastrutturale separata.
Cloud: il backup può essere policy-driven e integrato nei servizi.

Disaster recovery come grande progetto contro disaster recovery come architettura

Il disaster recovery tradizionale richiede spesso un secondo sito, hardware duplicato, contratti di replica, test periodici e runbook complessi.

Il cloud può ridurre la barriera al disaster recovery consentendo di definire l’infrastruttura come codice, ricreare ambienti e replicare dati tra region o account. Tuttavia, il disaster recovery nel cloud non è automatico. Recovery time, recovery point, dipendenze, DNS, identità, stato applicativo e test devono comunque essere progettati e pianificati.

On-premises: il disaster recovery spesso richiede infrastruttura fisica duplicata.
Cloud: il disaster recovery può essere automatizzato e guidato dall’architettura.

IT come centro di costo contro IT come motore di valore

Negli ambienti tradizionali, l’IT è spesso visto come un centro di costo che deve controllare la spesa e mantenere i sistemi in funzione.

Nelle organizzazioni abilitate dal cloud, l’IT può diventare un motore di valore: lanciare prodotti più velocemente, entrare in nuovi mercati, scalare servizi digitali, migliorare l’esperienza dei clienti, abilitare analytics e accelerare la sperimentazione. Questo è uno dei messaggi più importanti per i business leader. Il cloud non riguarda principalmente server più economici. Riguarda il cambiamento della velocità e della flessibilità del business.

On-premises: l’IT spesso si concentra su asset management e stabilità operativa.
Cloud: l’IT può concentrarsi di più su velocità, valore, sperimentazione e capacità di business.

Outsourcing tradizionale contro outsourcing cloud

Il cloud è una forma di outsourcing perché il provider gestisce l’infrastruttura sottostante. Ma è molto diverso dall’outsourcing tradizionale. L’outsourcing tradizionale spesso funziona tramite contratti, ticket, richieste di servizio e impegni lunghi.

Il cloud funziona tramite API, self-service, trasparenza, misurazione e provisioning rapido. Questa distinzione conta. Il cloud non dovrebbe essere trattato come un altro contratto di outsourcing. Richiede competenze interne in architettura, sicurezza, automazione, gestione dei costi e governance.

On-premises: basato su richieste e pesante sul piano contrattuale.
Cloud: API-driven, trasparente, elastico e orientato ai servizi.

Standardizzazione per restrizione contro standardizzazione tramite pattern riutilizzabili

On-premises, standardizzare spesso significa restringere le scelte: tipi di server approvati, database approvati, middleware approvato, pattern di rete approvati.

Nel cloud, la standardizzazione può essere ottenuta tramite pattern riutilizzabili: landing zone, strutture account, blueprint di rete, moduli Terraform riutilizzabili, immagini container approvate, baseline di sicurezza, librerie policy-as-code.

On-premises: standardizzazione spesso significa limitare manualmente le opzioni.
Cloud: la standardizzazione può essere incorporata in pattern automatizzati riutilizzabili.

Inventario fisico contro inventario digitale

L’inventario infrastrutturale tradizionale è spesso conservato in CMDB, fogli di calcolo, strumenti di monitoraggio, sistemi di procurement e diagrammi di rete. Può essere incompleto o non aggiornato.

Le risorse cloud sono create tramite API e possono essere scoperte, taggate, interrogate, inventariate e monitorate continuamente. Questo rende possibile una migliore visibilità degli asset, ma solo se tagging, struttura degli account, naming, ownership e governance sono progettati correttamente.

On-premises: l’inventario è spesso mantenuto manualmente o richiede strumenti di terze parti.
Cloud: l’inventario può essere scoperto e governato continuamente.

Mentalità della scarsità contro abbondanza con responsabilità

On-premises, l’infrastruttura è scarsa. I team competono per capacità, ambienti e attenzione delle operations.

Il cloud crea un senso di abbondanza, a volte falso. I team possono creare risorse rapidamente. Ma l’abbondanza senza responsabilità porta a sprechi, rischi di sicurezza e proliferazione architetturale. La mentalità cloud matura non è “usa quello che vuoi”. È “usa ciò che ti serve, con visibilità, ownership e guardrail.”

Nota : l’elasticità del cloud non significa capacità infinita garantita. In AWS, la capacità EC2 on-demand è solitamente disponibile, ma non è garantita per ogni tipo di istanza, Availability Zone o momento. Per workload business-critical che devono scalare rapidamente fino a un livello specifico di capacità, potresti dover usare EC2 Capacity Reservations, Capacity Blocks, tipi di istanza diversificati, più Availability Zone o altre tecniche di capacity planning.

On-premises: la scarsità limita la velocità.
Cloud: l’abbondanza aumenta la velocità ma richiede disciplina.

Destinazione di migrazione contro percorso continuo

L’on-premises spesso dà l’impressione di uno stato target stabile: costruire il data center, distribuire la piattaforma, operarla per anni.

Il cloud evolve continuamente. Nuovi servizi, modelli di prezzo, funzionalità di sicurezza, region, architetture e best practice appaiono costantemente. Questo significa che l’adozione cloud non è un progetto di migrazione una tantum. È una capacità continua.

On-premises: ciclo di vita infrastrutturale relativamente stabile.
Cloud: evoluzione continua e decision-making continuo.

Infrastruttura posseduta contro infrastruttura condivisa

Una delle differenze più profonde tra un ambiente on-premises e il cloud pubblico è il passaggio da infrastruttura posseduta a infrastruttura condivisa.

In un modello on-premises tradizionale, l’azienda di solito possiede, affitta o controlla direttamente l’infrastruttura fisica: server, sistemi storage, apparati di rete, rack, sale data center, controlli di accesso fisico, sistemi di backup e talvolta persino l’edificio. Anche quando alcune operations sono esternalizzate, l’ambiente è tipicamente dedicato a una sola organizzazione.

Nel public cloud, l’infrastruttura sottostante è condivisa. Il cloud provider gestisce enormi pool di compute, storage, networking e servizi di piattaforma usati da molti clienti contemporaneamente. Ogni cliente è logicamente isolato, ma la piattaforma fisica è comune.

Questo è uno dei fondamenti dell’economia del cloud. Condividere l’infrastruttura permette al provider di ottenere economie di scala, maggiore utilizzo, capacità globale e costi unitari inferiori. Ma cambia anche il modello di sicurezza, compliance, governance e legale.

In un ambiente on-premises, l’organizzazione si fida delle proprie strutture, persone, strumenti e processi. Nel public cloud, l’organizzazione si fida anche dei meccanismi di isolamento del cloud provider, della sua disciplina operativa, degli impegni legali, dei controlli di compliance e dell’architettura dei servizi.

Questo non è necessariamente peggio. In molti casi, i controlli del cloud provider sono più forti di quelli che una singola azienda potrebbe costruire da sola. Ma il modello di responsabilità cambia. Sicurezza, compliance, data governance e rischio legale devono essere riprogettati intorno all’infrastruttura condivisa, non semplicemente copiati dal mondo on-premises.

I noisy neighbour sono un rischio negli ambienti cloud condivisi, dove più clienti o workload girano sulla stessa infrastruttura fisica sottostante. Se un workload consuma improvvisamente molte risorse condivise, come CPU, I/O disco, banda di memoria o capacità di rete, può degradare le prestazioni di altri workload che condividono la stessa piattaforma.

On-premises: infrastruttura dedicata, nessun noisy neighbour.
Cloud: infrastruttura condivisa, economia di scala.

Il cloud funziona meglio nelle economie di velocità

Hohpe contrappone le tradizionali “economie di scala” alle moderne “economie di velocità”.

L’IT tradizionale presuppone che il cambiamento sia eccezionale: definire un progetto, pianificare lo stato target, eseguire e tornare alla normalità. Le aziende digitali operano diversamente. Presuppongono cambiamento continuo. Imparano attraverso la sperimentazione, si adattano rapidamente e misurano il progresso tramite velocità, feedback e valore consegnato. Il cloud si adatta a questo modello perché prezza e fornisce risorse dinamicamente. Invece di acquistare infrastruttura in anticipo, le aziende consumano capacità secondo necessità. Per questo il libro dice che il cloud “pensa nella derivata prima”: si interessa a tassi di cambiamento, consumo, velocità e burn rate più che ad asset statici e budget fissi.

On-premises: il cambiamento è l’eccezione.
Cloud: cambiamento continuo e sperimentazione.

Procurement contro consumo

Due esempi classici di processi esistenti che non si adattano al modello cloud sono procurement e operations.

I budget IT tradizionali sono impostati almeno un anno in anticipo, rendendo la prevedibilità un elemento chiave. Il procurement IT tende a negoziare termini di licenza pluriennali per il software acquistato. Le aziende “bloccano gli sconti” sottoscrivendo pacchetti più grandi per accomodare eventuali aumenti d’uso nel tempo, pur non riuscendo a sfruttarli pienamente fin dall’inizio.

L’innovazione critica del cloud, e il motivo per cui ha trasformato l’IT, è il suo modello di pricing elastico: non paghi le risorse in anticipo, ma solo ciò che consumi realmente. Poiché i criteri di valutazione tradizionali funzionano male per il cloud, un approccio migliore è confrontare la visione della tua azienda con la strategia di prodotto e la filosofia del provider.

On-premises: contratti pluriennali e sconti.
Cloud: pagamento a consumo, con piani di sconto disponibili.

Aspetti di sicurezza e legali del cloud

Isolamento logico

In un ambiente on-premises, la sicurezza spesso inizia dal controllo fisico e di rete. L’azienda controlla chi entra nel data center, quale hardware viene installato, come sono segmentate le reti e quali sistemi sono fisicamente connessi.

Nel public cloud, il cliente non controlla più l’infrastruttura fisica. Invece, la sicurezza dipende fortemente dall’isolamento logico e dai controlli software-defined: identity and access management, cifratura, reti virtuali, security group, policy, chiavi, logging, monitoraggio e guardrail automatizzati.

Questo non significa che il cloud sia meno sicuro. I grandi cloud provider di solito dispongono di sicurezza fisica, hardware security, monitoraggio e disciplina operativa molto più forti di quanto la maggior parte delle singole aziende possa costruire da sola. Ma il cliente deve capire che il modello di sicurezza è cambiato. Il provider protegge l’infrastruttura cloud sottostante. Il cliente protegge il modo in cui i servizi cloud sono configurati e usati.

Questo è noto come modello di responsabilità condivisa. AWS descrive sicurezza e compliance come una responsabilità condivisa: AWS gestisce e controlla componenti dal sistema operativo host e dal livello di virtualizzazione fino alle strutture fisiche, mentre i clienti rimangono responsabili di workload, dati, identità, configurazioni e utilizzo dei servizi.

Multi-tenancy

Un fraintendimento comune è che “infrastruttura condivisa” significhi che i dati dei clienti siano mescolati. Non è così che un public cloud è progettato. Le piattaforme cloud usano meccanismi di isolamento tra tenant, come virtualizzazione, isolamento dei container, confini di identità, segmentazione di rete, cifratura e controllo degli accessi.

Tuttavia, la multi-tenancy cambia comunque il modello di rischio. Il cliente deve fidarsi del corretto funzionamento dei meccanismi di isolamento del provider. Vulnerabilità in hypervisor, runtime container, servizi gestiti, firmware, sistemi di identità o control plane possono diventare molto importanti perché molti clienti dipendono dalla stessa piattaforma sottostante.

Negli ambienti on-premises, una vulnerabilità hardware o di virtualizzazione di solito colpisce una sola organizzazione. Nel public cloud, una grave vulnerabilità della piattaforma condivisa potrebbe teoricamente colpire molti clienti, anche se i provider investono molto per prevenirlo.

Compliance

In un ambiente posseduto, l’azienda può documentare, ispezionare e auditare direttamente gran parte dell’infrastruttura . Può mostrare dove si trovano i server, chi ha accesso fisico, come sono conservati i backup e come sono configurati gli apparati di rete.

Nel cloud, l’azienda non può ispezionare personalmente ogni data center o server fisico. Si affida invece alle certificazioni del provider, ai report di audit, ai programmi di compliance, agli impegni contrattuali e ai controlli tecnici.

La compliance cloud richiede quindi di mappare le responsabilità. Per ogni regolamento o policy interna, l’organizzazione deve identificare se il controllo è gestito dal provider, dal cliente o condiviso.

Data governance

In un ambiente on-premises, la localizzazione dei dati può essere più facile da concettualizzare: i dati sono nel data center dell’azienda, nel sito di backup o nella piattaforma storage.

Nel cloud, i dati possono esistere attraverso più servizi e forme: object storage, database, snapshot, log, metriche, code, piattaforme analytics, dataset di machine learning, backup, repliche, cache temporanee e metadati.

Questo rende la data governance più importante, non meno.

Un’azienda deve definire:

• quali dati sono consentiti nel cloud;
• quali region possono essere utilizzate;
• quali servizi possono memorizzare dati regolamentati;
• come sono classificati i dati;
• chi possiede ciascun dataset;
• come sono gestite le chiavi di cifratura;
• per quanto tempo i dati vengono conservati;
• come sono gestiti backup e repliche;
• se i log contengono dati personali o sensibili;
• se anche i metadati sono sensibili;
• come i dati vengono cancellati o esportati.

Il cloud rende facile creare copie dei dati. Questo è utile per analytics, resilienza e backup, ma pericoloso senza governance.

Giurisdizione legale

Con infrastruttura posseduta, la giurisdizione legale è spesso più facile da ragionare perché l’azienda sa dove si trova il data center, quale entità legale lo gestisce e quale legge nazionale si applica.

Nel public cloud, il quadro è più complesso. Il cliente può scegliere una region europea, ma il provider può avere sede in un altro paese. Supporto, operations, billing, metadati, subappaltatori e obblighi legali possono coinvolgere più giurisdizioni.

Per le organizzazioni europee, questo è particolarmente importante perché il GDPR limita i trasferimenti di dati personali al di fuori dello SEE, a meno che il trasferimento sia conforme al Capitolo V del GDPR. L’European Data Protection Board spiega che i dati personali possono essere trasferiti fuori dallo SEE solo nel rispetto di tali condizioni, per garantire che il livello di protezione rimanga essenzialmente equivalente.

Questo è il motivo per cui “data residency” e “data sovereignty” non sono la stessa cosa. Una region cloud in Europa può aiutare con la residency, ma la sovereignty dipende anche da contratti, cifratura, gestione delle chiavi, accesso del supporto, gestione dei metadati, controllo operativo e giurisdizione legale.

Accesso governativo

In un data center posseduto, una richiesta o un sequestro governativo è di solito rivolto all’organizzazione che gestisce l’ambiente.

Nel public cloud, le preoccupazioni sull’accesso governativo possono coinvolgere sia il cliente sia il provider. Un’autorità pubblica può richiedere dati al cliente, ma in alcune circostanze può anche emettere richieste legali al cloud provider, a seconda della legge applicabile.

Questo non significa che i governi possano accedere liberamente ai dati cloud. I principali provider di solito richiedono un valido procedimento legale, pubblicano transparency report e possono contestare richieste eccessivamente ampie. Ma dal punto di vista della gestione del rischio, il cliente deve considerare la giurisdizione del provider e l’esposizione legale.

Questo è uno dei motivi per cui esistono le offerte sovereign cloud. Cercano di ridurre il rischio aggiungendo controlli più forti su localizzazione dei dati, accesso operativo, governance locale, cifratura e personale di supporto.

Cifratura e gestione delle chiavi

In un modello di infrastruttura condivisa, la cifratura diventa più di una best practice tecnica. Diventa un controllo di governance e legale. Per workload molto sensibili, la domanda chiave non è solo “i dati sono cifrati?”, ma “chi controlla le chiavi?”.

Se il cliente controlla correttamente le chiavi (al di fuori del cloud stesso), il rischio di accesso non autorizzato lato provider viene ridotto o rimosso completamente. Tuttavia, la gestione delle chiavi introduce anche responsabilità operative: perdere le chiavi può significare perdere l’accesso ai dati.

Auditabilità e trasparenza

Il cloud può migliorare l’auditabilità perché molte azioni sono API-driven e possono essere registrate: chi ha creato una risorsa, chi ha modificato una policy, chi ha avuto accesso a un secret, chi ha modificato una regola di rete, chi ha copiato dati e quale servizio ha generato costi.

Questo può essere migliore rispetto a molti ambienti tradizionali, dove le modifiche possono avvenire manualmente e la documentazione può essere incompleta. Tuttavia, il cloud crea anche più elementi da auditare. Ci sono più servizi, più identità, più ruoli macchina, più API, più log, più region, più account, più pipeline di automazione e più risorse temporanee.

Il modello di audit cambia da ispezione periodica a monitoraggio continuo.

Incident response

In un ambiente on-premises, l’organizzazione può ispezionare direttamente server, storage, apparati di rete, log e infrastruttura fisica.

Nel cloud, il cliente può investigare solo ciò che controlla: account, workload, log, IAM, configurazione di rete, comportamento applicativo, accesso ai dati e utilizzo dei servizi. Il provider investiga la piattaforma cloud sottostante. Questo richiede nuovi playbook di incident response, scritti da zero per l’ambiente cloud.

Cancellazione e ciclo di vita dei dati

In un ambiente posseduto, la cancellazione dei dati è comunque difficile, ma l’organizzazione ha un controllo più diretto su dischi, nastri, sistemi di backup e policy di retention.

Nel cloud, i dati possono esistere in più livelli: storage primario, repliche, snapshot, backup, log, archivi, interni dei servizi gestiti e copie di disaster recovery. I cloud provider di solito offrono meccanismi documentati di cancellazione e retention, ma il cliente deve capire come ciascun servizio gestisce il ciclo di vita dei dati.

Il lato oscuro del cloud

Il cloud è potente, ma non è automaticamente più economico, sicuro, semplice o resiliente. Riduce alcuni rischi introducendone altri: rischio di concentrazione, volatilità dei costi, complessità dell’identità, skill gap operativi e dipendenza dal provider. Un’adozione cloud di successo richiede scelte architetturali consapevoli, governance forte, gestione continua dei costi, maturità di sicurezza e una chiara comprensione che il cloud non è una destinazione, ma un modello operativo continuo.

Outage: quando piove, diluvia

Parametrix è una società di assicurazione e analytics focalizzata sul rischio di interruzione digitale del business, in particolare outage di piattaforme cloud, CDN, piattaforme ecommerce e altri servizi digitali critici di terze parti.

Il Cloud Outage Risk Report 2025 di Parametrix evidenzia un cambiamento significativo nel panorama dell’affidabilità cloud, guidato dalla rapida adozione dell’Artificial Intelligence (AI) e dall’aumento della domanda di compute. Sebbene la stabilità complessiva del cloud sia migliorata nel 2025 rispetto ai tre anni precedenti, l’impatto di specifici guasti regionali è rimasto sostanziale.

Affidabilità dei cloud provider:

• Trend di affidabilità: dopo un aumento del downtime dal 2022 al 2024, nel 2025 si è registrata una diminuzione dell’8,2% nel numero di eventi di downtime “critici” (da 49 a 45). La durata sarebbe scesa da 244,8 ore nel 2024 a 175,3 ore nel 2025. Questo miglioramento è stato dovuto principalmente a un primo semestre stabile.
• Impatto per servizio e regione: il Nord America rimane la regione più volatile, rappresentando oltre la metà di tutti gli eventi cloud nel 2024 e 2025. Grandi interruzioni si sono verificate in region chiave come AWS us-east-1 e GCP us-central1. I servizi compute continuano a essere il principale driver del downtime.
• Cause principali: l’errore umano è la causa principale di tutti gli eventi cloud (51% degli eventi critici). Tuttavia, le interruzioni di alimentazione (30% degli eventi critici) hanno un impatto sproporzionatamente elevato, spesso innescando guasti totali del servizio pur essendo relativamente rare.

Principali incidenti del 2025:

• Google Cloud (12 giugno): un aggiornamento errato di una quota policy ha causato un outage di quasi tre ore, impattando gravemente la region us-central1.
• AWS (20 ottobre): un errore DNS e di automazione in us-east-1 ha causato oltre 14 ore di disservizio, con perdite finanziarie stimate tra 500 e 650 milioni di dollari per le aziende statunitensi.
• Microsoft Azure (29 ottobre): una modifica di configurazione in Azure Front Door ha causato problemi globali di latenza e connettività durati oltre 8 ore.

Vendor lock-in

Gestire proprie strutture concentra il rischio localmente: sei responsabile del data center fisico, degli stack di networking, dei cicli di vita hardware, del personale interno e delle relazioni con i fornitori.

Pur mitigando queste vulnerabilità locali, il cloud introduce rischio di concentrazione. Un singolo provider hyperscale, una specifica region o un servizio fondamentale come IAM o DNS può diventare un single point of failure critico per un intero portafoglio applicativo.

Questo non significa che il cloud sia fragile — i provider investono miliardi in resilienza — ma richiede che l’architettura cloud tenga conto del rischio di dipendenza sistemica.

La forza del public cloud risiede nei servizi gestiti, dove i clienti sfruttano una piattaforma condivisa e gestita dal provider. Questo consente alle organizzazioni di consumare database, analytics e capacità AI come servizi di livello utility, invece di costruire tutto da zero.

Tuttavia, queste capacità creano un compromesso. Un uso profondo di funzionalità specifiche del provider può accelerare la velocità, ma allo stesso tempo aumenta la complessità di una futura migrazione . Resistere a questi servizi può ridurre il lock-in, ma spesso al costo del valore intrinseco del cloud.

Il lock-in è una realtà commerciale tanto quanto tecnica. Autorità regolatorie come Ofcom hanno osservato che egress fee, sconti basati su impegni e restrizioni di piattaforma possono rendere difficili per le imprese strategie multi-cloud o cambi di provider.

Il cloud promette agilità, ma le strutture finanziarie spesso incentivano la concentrazione. Una volta che dati, pipeline di automazione e competenze tecniche sono legati a un ecosistema, la nozione di “scelta” può diventare in larga parte accademica.

I servizi gestiti rappresentano il più grande paradosso del cloud. Riducono l’“undifferentiated heavy lifting” delle operations, ma aumentano la dipendenza da API proprietarie, framework IAM e logiche operative specifiche del provider. Evitare aggressivamente i servizi proprietari per sfuggire al lock-in può essere controproducente. Hohpe avverte che questo spesso produce un “enterprise non-cloud”: un ambiente cloud che funziona di fatto come un data center legacy.

Molte aziende migrano restando attaccate a cicli di approvazione rigidi, governance manuale e modelli operativi a silos. Questo approccio non realizza una trasformazione cloud; crea semplicemente una versione più costosa e in outsourcing del data center esistente. L’obiettivo di una strategia matura non è eliminare tutte le dipendenze, ma sceglierle con intenzione consapevole.

Gli hyperscaler sono altamente resilienti, ma sono anche profondamente incorporati in migliaia di aziende, governi, banche, piattaforme SaaS e supply chain. Questo crea rischio di concentrazione: un grande outage del provider, un problema del servizio di identità, un guasto DNS, un incidente regionale o un problema di control-plane può avere conseguenze ampie.

I regolatori trattano sempre più il cloud come infrastruttura critica. L’indagine CMA sul cloud e il referral Ofcom mostrano che la concentrazione cloud non è più solo una questione di architettura IT; è anche una questione di concorrenza, resilienza e politica economica.

Passare a un hyperscaler può ridurre il rischio della tua infrastruttura locale aumentando però la dipendenza da un piccolo numero di piattaforme globali.

Picchi di costo

Il lato oscuro dell’adozione cloud è che le organizzazioni spesso lo trattano semplicemente come una forma di hosting più economica. In realtà, il cloud rappresenta un cambiamento fondamentale nei modelli economici, operativi, di sicurezza e organizzativi. Questi problemi sistemici emergono tipicamente dopo la migrazione, quando l’utilizzo scala, le dipendenze da servizi gestiti proprietari si approfondiscono e i dipartimenti finance iniziano a chiedersi perché i costi non stiano diminuendo.

In Cloud Strategy, Gregor Hohpe sottolinea che i benefici finanziari non sono garantiti; devono essere “earned”, guadagnati, attraverso disciplina architetturale. Portare nel cloud il bagaglio legacy enterprise senza trasformazione spesso produce un “enterprise non-cloud”: una configurazione che imita un data center tradizionale ma a un prezzo più alto.

Secondo il report Flexera 2026 State of the Cloud, il 68% dei rispondenti indica la cost optimization come iniziativa principale. Il report identifica inoltre ostacoli critici alla migrazione, tra cui la difficoltà di confrontare spese on-premises e cloud, scegliere tipi di istanza appropriati e mantenere controllo fiscale dopo lo spostamento iniziale.

L’IT convenzionale, ostacolata da una trasparenza limitata, spesso si affida a governance restrittiva: limitare l’accesso degli sviluppatori, bloccare cambiamenti infrastrutturali e richiedere approvazioni manuali. Questi workflow legacy creano attrito significativo e sono fondamentalmente in contrasto con le pratiche moderne di DevOps e Continuous Delivery.

Le architetture moderne generano una quantità enorme di telemetry, inclusi log applicativi, metriche di performance, distributed trace e audit trail di sicurezza. È una notevole ironia che proprio i dati di osservabilità necessari per governare l’ambiente possano trasformarsi in un peso finanziario sostanziale.

Business case semplicistici spesso trascurano questa realtà operativa. Tuttavia, senza visibilità robusta i team non possono gestire efficacemente affidabilità del sistema o salute finanziaria. Al contrario, catturare dati eccessivi e non filtrati può generare fatture provider inaspettatamente elevate. Ottenere visibilità completa sulle operations cloud è tutt’altro che un obiettivo a costo zero.

Sicurezza

I cloud provider proteggono la piattaforma cloud, ma i clienti mantengono molte responsabilità critiche: identità, protezione dei dati, policy di accesso, sicurezza applicativa, configurazione di rete, logging e controlli specifici dei servizi.

Una scheda informativa NSA sulla cybersecurity del 2024 avverte che i clienti spesso assumono erroneamente che il cloud provider gestisca salvaguardie che restano invece responsabilità del cliente, e afferma che misconfigurazioni e mancanza di controlli di sicurezza sono rischi significativi negli ambienti cloud.

Nel cloud, identità e permessi sono infrastruttura. Una policy IAM errata, una access key esposta, un ruolo CI/CD eccessivamente privilegiato o un account admin compromesso possono esporre molto più di un singolo server. Questo viene raramente spiegato ai business leader: il passaggio da sicurezza basata sulla rete a sicurezza basata sull’identità richiede un approccio molto più maturo a least privilege, rotazione delle chiavi, service account, credenziali temporanee e monitoraggio continuo.

Invece di affidarsi a restrizioni manuali, la trasparenza intrinseca del cloud abilita guardrail automatizzati. Questo consente il rilevamento in tempo reale delle violazioni delle policy, rafforzando la compliance e riducendo al tempo stesso il peso procedurale sui team di engineering.

Il report IBM 2025 Cost of a Data Breach colloca il costo medio globale di una violazione a 4,44 milioni di dollari e mette in evidenza i rischi derivanti dall’adozione rapida della tecnologia senza governance adeguata.

I fallimenti di sicurezza cloud spesso non sono causati da cloud provider deboli, ma da un design debole delle identità e da una governance debole.

Complessità cloud-native e rendimenti decrescenti

Container, Kubernetes, service mesh, serverless, architetture event-driven, IaC, GitOps, policy-as-code e piattaforme di osservabilità possono essere potenti. Possono anche creare uno skill cliff.

La survey CNCF 2024 osserva che l’adozione cloud-native continua a crescere, con un quarto dei rispondenti che dichiara che quasi tutto il loro sviluppo e deployment usa tecniche cloud-native. Ma l’adozione crescente significa anche che le organizzazioni hanno bisogno di nuove competenze operative, non solo di nuovi strumenti.

Il cloud non è una migrazione una tantum. Crea un bisogno continuo di platform engineering, FinOps, security engineering, cloud architecture, automazione, SRE, vendor management e competenze di compliance.

Il problema nascosto non è solo assumere cloud engineer. È che ogni progetto futuro eredita il modello operativo cloud. Hohpe descrive il cloud come un “lifestyle change”, non come un esercizio di procurement.

Il cloud-native può ridurre l’attrito infrastrutturale aumentando al tempo stesso la complessità architetturale e operativa.

Il business case spesso ignora il costo organizzativo

I business case cloud spesso confrontano il costo infrastrutturale: server contro risorse cloud. Possono sottostimare lo sforzo di migrazione, formazione, progettazione della landing zone, tooling di sicurezza, refactoring, dual-running durante la migrazione, FinOps, compliance, governance architetturale e ridisegno operativo.

I risultati Flexera 2026 sulla migrazione mostrano che comprensione delle dipendenze e fattibilità tecnica sono sfide importanti, esattamente le aree che i business case semplicistici tendono a sottostimare.

Il piano di migrazione cloud più economico è spesso quello che ha dimenticato il lavoro reale.

Conclusione

Il cloud non è semplicemente un posto diverso in cui eseguire server. È un modello operativo diverso, costruito intorno a consumo di servizi, automazione, elasticità, responsabilità condivisa e cambiamento continuo. Il suo vero valore deriva da velocità, leva e accesso a capacità gestite che per la maggior parte delle organizzazioni sarebbero difficili da costruire da sole. Ma questi benefici non sono automatici: richiedono disciplina architetturale, governance forte, consapevolezza dei costi, maturità di sicurezza e nuove abitudini organizzative. Una cloud strategy di successo quindi non parte dalla migrazione, ma dalla comprensione di cosa deve cambiare nel modo in cui il business finanzia, costruisce, protegge, gestisce ed evolve la tecnologia.