Sei un'azienda retail con un sistema gestionale (ERP) perfettamente stabile e stai valutando di aggiungere un agente AI che aggiorni i prezzi sul tuo sito in tempo reale?
L'agente controlla il magazzino, calcola gli sconti, suggerisce i prodotti correlati.
In teoria, un'ora di lavoro automatizzata, in pratica, ogni volta che un utente effettua una ricerca, il sistema mette in moto decine di operazioni in parallelo, il database va in affanno e il sito rallenta.
Non è un problema di codice, ma di architettura.
Google ha introdotto il concetto di fluid compute, un'infrastruttura intelligente che sposta la potenza di calcolo in tempo reale dove serve di più, unendo i programmi tradizionali alle nuove funzioni AI.
Google Cloud Next '26 - l’evento annuale che Google tiene a Las Vegas - ha messo al centro la scalabilità e l'efficienza dei sistemi. Ecco le novità infrastrutturali che possono fare la differenza rispetto a costi e prestazioni per aziende come la tua già da oggi.
Torniamo all'esempio del retailer.
Il problema non è che il sito sia mal sviluppato, è che i server su cui gira sono stati progettati per un mondo in cui le operazioni arrivano in sequenza, non tutte insieme.
I processori x86 tradizionali gestiscono i picchi di carico “sdoppiando” ogni core fisico in due canali virtuali, una tecnica chiamata Simultaneous Multithreading. Funziona bene fino a un certo punto, dopodiché i due canali si contendono le stesse risorse e le prestazioni diventano imprevedibili proprio quando servirebbero stabili.
I nuovi processori Google Axion eliminano questo compromesso alla radice.
Ogni unità di calcolo corrisponde a un core fisico reale: nessuna condivisione, nessuna variabile nascosta sotto carico.
Il risultato è un comportamento del sistema molto più prevedibile, che si traduce in latenza stabile anche nei momenti di punta e in una bolletta cloud più contenuta.
Google ha sviluppato due famiglie distinte di processori, con filosofie opposte.
Le istanze N4A sono la risposta per chi gestisce molti server in parallelo e vuole ridurre il costo complessivo senza sacrificare affidabilità.
Rispetto ai server x86 di generazione precedente, offrono fino al 105% di miglioramento nel rapporto prezzo/prestazioni e un consumo energetico inferiore fino all'80%.
Considera il caso di un'azienda manifatturiera con un sistema ERP distribuito su trenta microservizi, ognuno su una macchina separata. Ogni mese quella flotta pesa decine di migliaia di euro.
Migrando su istanze N4A, spesso senza modificare una riga di codice applicativo, quella stessa azienda può aspettarsi risparmi reali sulla bolletta mensile, sia rispetto all'equivalente x86 che rispetto alle più costose C4A. Il guadagno non viene dalla velocità del singolo server, ma dall'efficienza complessiva della flotta.
Le N4A danno il meglio nelle architetture che scalano orizzontalmente: server web, microservizi, container su Google Kubernetes Engine (GKE), applicazioni Java enterprise, pipeline di compilazione e job batch. Sono anche la scelta giusta per eseguire modelli AI leggeri già addestrati direttamente su CPU, senza pagare GPU dedicate.
Se le N4A sono la scelta dell'efficienza, le C4A sono la scelta della potenza. Sono progettate per situazioni in cui ogni millisecondo ha un costo reale e il picco di carico deve essere assorbito senza esitazioni.
Pensa a una piattaforma di pagamenti online che processa transazioni in tempo reale. Il database deve rispondere in meno di dieci millisecondi, anche con migliaia di richieste simultanee. Le C4A raggiungono i 100 Gbps di banda di rete e possono collegare dischi SSD fisici locali (Titanium SSD) direttamente al server, eliminando il salto di latenza che normalmente si paga passando per lo storage di rete. Nei calcoli a singolo thread, nella compressione dati e nella crittografia AES si dimostrano fino al 100% più veloci delle N4A.
I contesti in cui fanno la differenza sono database transazionali ad alto traffico come PostgreSQL o Cloud SQL, infrastrutture di caching come Redis o Memcached, server di gioco online e sistemi AdTech, dove la latenza variabile si traduce direttamente in mancato fatturato.
La scelta tra le due famiglie si riduce a una domanda sola: il tuo problema principale è il costo della flotta o la velocità del singolo processo? Nel primo caso N4A, nel secondo C4A.
| C4A | N4A | |
| Obiettivo primario | Prestazioni e bassa latenza | Efficienza e riduzione dei costi |
| Architettura | Arm Neoverse V2 | Arm Neoverse N3 |
| Banda di rete massima | 100 Gbps | 50 Gbps |
| Storage locale | SSD Titanium fino a 6 TB | Solo storage di rete |
| Configurazioni | Predefinite e bare metal | Predefinite e personalizzabili |
| Costo relativo | Tariffa base | ~14% più economica |
Chiedici come Google Cloud Platform può supportare ed evolvere l'infrastruttura della tua azienda.
C'è una categoria di carichi di lavoro per cui qualsiasi strato di virtualizzazione è già troppo: simulazioni industriali di fluidodinamica, rendering 3D in produzione, test continui di firmware embedded, sviluppo di applicazioni che devono girare su hardware specifico.
In questi contesti, la virtualizzazione introduce una variabile che non riesci a controllare e che nei momenti peggiori diventa un collo di bottiglia impossibile da diagnosticare.
Le nuove istanze C4A.metal risolvono questo problema mettendo i processori Axion direttamente a disposizione dell'applicazione, senza filtri software intermedi.
L'accesso bare metal (cioè alla macchina fisica pura) era già disponibile su altre famiglie Google Cloud, ma portarlo sui nuovi Axion significa combinare la potenza del chip di ultima generazione con la prevedibilità assoluta dell'hardware dedicato.
Per le aziende che hanno sempre tenuto i carichi più pesanti su server fisici in sede perché il cloud "non reggeva", questa opzione apre per la prima volta una strada credibile verso la nuvola senza dover accettare compromessi prestazionali.
Un agente AI non è un chatbot. Un chatbot risponde a domande, un agente esegue azioni, accede a database, chiama API esterne, genera e lancia codice in modo autonomo. Questo è il suo valore, ma è anche il rischio che molte aziende sottovalutano fino al primo incidente.
Per restare sull’esempio del retailer, l'agente AI deve aggiornare i prezzi in base alla disponibilità di magazzino, tutto funziona correttamente per settimane.
Poi arriva un input anomalo, un prodotto con una codifica insolita o un valore fuori scala, e l'agente genera un comando errato.
Se quel comando viene eseguito direttamente sui sistemi aziendali, il risultato può essere un aggiornamento massiccio di prezzi sbagliati, un blocco del database o, nel caso peggiore, una falla di sicurezza aperta verso l'esterno.
GKE Agent Sandbox è quel layer. Crea un ambiente isolato in cui l'agente esegue i suoi comandi senza avere accesso reale ai sistemi aziendali. Se qualcosa va storto, l'errore rimane confinato, la sandbox si distrugge in pochi secondi e il sistema principale non ne sa nulla. Quando invece tutto funziona correttamente, il risultato viene propagato ai sistemi reali in modo controllato e verificabile.
Dal punto di vista dei costi, la sandbox sfrutta le istanze Axion N4A, che la rendono strutturalmente più veloce del 30% rispetto alle soluzioni equivalenti di AWS e Azure, con un impatto contenuto sulla bolletta. Per un'azienda che sta portando il primo agente in produzione è la differenza tra un lancio controllato e una crisi da gestire il giorno dopo.
Conosci Gemini Enterprise? È la piattaforma agentica di Google che connette sistemi eterogenei e permette di costruire agenti AI che producono sintesi, svolgono azioni, forniscono previsioni e segnali di alert proattivi.
Ne abbiamo parlato nel nostro webinar “Gemini Enterprise come usare gli agenti AI sui dati reali aziendali”, ma se hai pochi minuti puoi leggere la nostra breve guida qui!
I Committed Use Discount (CUD) sono il meccanismo con cui Google premia le aziende che si impegnano a usare i suoi servizi per un periodo definito, tipicamente uno o tre anni. La logica è semplice: tu garantisci prevedibilità, Google riduce la tariffa.
Fino ad oggi, però, questa flessibilità aveva un limite pratico: gli sconti si applicavano a un insieme ristretto di server standard, e spostarsi da una risorsa all'altra, o da una regione all'altra, significava spesso perdere le agevolazioni già attive.
Con gli aggiornamenti annunciati a Cloud Next '26, la copertura si allarga in modo significativo. I CUD si applicano ora alle istanze ottimizzate per memoria dalla serie M1 alla M4, ai sistemi di calcolo intensivo H3 e H4D, e a Cloud Run, la piattaforma che permette di eseguire applicazioni containerizzate senza gestire l'infrastruttura sottostante.
Cosa cambia in concreto? Un'azienda che oggi paga Cloud Run a consumo per i suoi microservizi può impegnarsi su un volume mensile, ottenere uno sconto strutturale e spostare il budget risparmiato verso altri servizi senza perdere le agevolazioni già attive.
Per un CFO o un responsabile IT significa trasformare una voce di spesa variabile e difficile da prevedere in un costo pianificabile con più margine per investire dove serve davvero.
Vuoi ottimizzare i costi infrastrutturali di Google Cloud? Leggi la nostra guida.
Nella maggior parte delle aziende i dati non vivono in un posto solo: il CRM è su Salesforce, i dati storici di vendita stanno su AWS S3, i sistemi gestionali girano su Azure o su server fisici in sede.
Quando vuoi usare l'AI di Google Cloud per analizzare tutto questo insieme, ti scontri con un problema concreto, spostare grandi volumi di dati tra cloud diversi è lento, complicato e costoso, sia in termini di ore tecniche che di tariffe di trasferimento.
Gli annunci di Cloud Next '26 affrontano questo problema da due direzioni.
Da un lato, Google ha potenziato i collegamenti diretti e sicuri con AWS e Azure, riducendo latenza e costi di trasferimento tra reti. Dall'altro, ha introdotto un cross-cloud Lakehouse nell'Agentic Data Cloud: un'architettura che permette ai tuoi agenti AI di interrogare i dati dove si trovano, senza doverli prima copiare su Google Cloud.
Il risultato pratico è che un agente può accedere in modo nativo a dati su AWS, elaborarli con i modelli Google e scrivere i risultati dove serve, senza che il tuo team debba costruire e mantenere pipeline di sincronizzazione tra ambienti diversi. Per chi ha costruito un'infrastruttura multi-cloud nel tempo questa è la strada per iniziare a sfruttare l'AI senza dover rimettere in discussione l'architettura esistente.
Le novità di Cloud Next '26 non richiedono di riprogettare tutto. Richiedono di capire dove sei oggi e dove ha senso intervenire per primo.
Vuoi un'analisi del tuo ecosistema Google Cloud? Prenota un meet con il nostro team, ottimizziamo insieme costi, sicurezza e prossimi passi.
Non è necessario farlo tutto in una volta. La strategia più efficace è identificare i carichi di lavoro con il costo più alto, tipicamente le flotte di microservizi o i server web, e testarli prima su istanze N4A. Google offre strumenti di migrazione graduali che permettono di spostare singoli servizi senza toccare il resto dell'infrastruttura. Un buon punto di partenza è un'analisi comparativa prima di qualsiasi intervento.
Sì, può essere introdotta anche su ambienti esistenti. In alcuni casi richiede una revisione dell'architettura di deployment, ma è progettata per integrarsi con i cluster Kubernetes già attivi. È un intervento che conviene pianificare con un tecnico prima di farlo in autonomia, soprattutto se l'agente è già in produzione.
No, gli impegni esistenti rimangono nelle condizioni originali fino alla scadenza. Le nuove coperture si applicano ai contratti stipulati da questo momento in poi. Se hai impegni in scadenza nei prossimi mesi, è il momento giusto per rinegoziare prima del rinnovo automatico.
È l'insieme di tecnologie che permette a Google Cloud di connettersi in modo diretto e sicuro con altri provider come AWS e Azure. La novità rispetto al passato è che non richiede di spostare i dati: gli agenti AI di Google possono interrogarli dove si trovano, riducendo latenza, costi di trasferimento e complessità tecnica.
Non necessariamente. Cloud Run ha senso quando vuoi eseguire applicazioni containerizzate senza gestire l'infrastruttura sottostante. Se ci sei già, o stai valutando il passaggio per motivi tecnici, il fatto che ora rientri nei CUD è un vantaggio economico concreto. Ma non è una ragione sufficiente da sola per migrare: la decisione deve partire dall'architettura, non dallo sconto.