Cloud Run Instances rende persistente il serverless e AWS amplia il livello dati

☁️ Punti chiave

• Cloud Run Instances introduce runtime singleton persistenti, arrestabili e riavviabili, progettati per agenti AI e container che non possono scalare a zero.
• AWS Glue 6.0 supporta dati geospaziali, timestamp al nanosecondo e payload variant direttamente nelle tabelle Apache Iceberg v3.
• Amazon MQ può autenticare operatori e workload attraverso provider OAuth differenti, applicando permessi distinti sullo stesso broker RabbitMQ.

Google Cloud estende il modello serverless ai carichi containerizzati persistenti con Cloud Run Instances, runtime singleton destinati soprattutto ad agenti AI personali e processi che devono rimanere attivi anche senza un flusso continuo di richieste. Parallelamente, Pythian formalizza un modello operativo per misurare il ritorno degli investimenti AI, mentre AWS amplia il livello dati con i nuovi tipi di Apache Iceberg v3 su Glue 6.0 e un’architettura multi-provider OAuth per Amazon MQ. Le quattro iniziative intervengono su problemi differenti ma collegati: durata dell’esecuzione, misurazione del valore, flessibilità degli schemi e separazione delle identità. Il cloud gestito non elimina la complessità, ma prova a renderla configurabile senza riportare ogni workload su macchine virtuali amministrate manualmente.

Cloud Run Instances occupa lo spazio tra serverless e macchina virtuale

Cloud Run è stato progettato principalmente per servizi stateless che rispondono alle richieste, aumentano il numero delle repliche durante i picchi e possono scalare a zero quando il traffico scompare. Questo comportamento è conveniente per API e applicazioni web, ma diventa poco adatto a un agente personale che deve rimanere raggiungibile, conservare una sessione e operare in un’unica copia. Una macchina virtuale risolve il problema della persistenza, ma obbliga a pagare risorse dedicate, aggiornare il sistema operativo, gestire firewall e configurare gli endpoint HTTPS. Cloud Run Instances introduce un runtime singleton senza autoscaling, accessibile attraverso un indirizzo HTTPS stabile anche dopo aggiornamenti e riavvii. Ogni esecuzione può durare fino a sette giorni e viene riavviata automaticamente secondo la policy predefinita, consentendo al workload di proseguire oltre la durata della singola istanza. La risorsa può inoltre essere arrestata quando non serve e ripresa successivamente. Google indica un costo di 5,70 dollari per mantenere in funzione per trenta giorni una configurazione con una vCPU condivisa e un GiB di memoria. Il modello utilizza budget di burst della CPU: è quindi adatto a processi che restano attivi a lungo ma richiedono capacità più elevata soltanto durante alcune operazioni, non a calcoli intensivi e continui. La presentazione ufficiale di Cloud Run Instances utilizza come esempio OpenClaw, agente open source normalmente eseguito su un computer personale. Configurazione e stato possono essere montati da Cloud Storage, mentre l’agente rimane raggiungibile attraverso Telegram, WhatsApp o altri canali anche quando il portatile dell’utente è spento. La funzione è disponibile in anteprima e Google anticipa anche il futuro supporto SSH per Cloud Run Instances e Cloud Run services.

Leggi anche: Google lancia Agent Executor per agenti AI distribuiti e sicuri sul cloud

Il serverless persistente risolve alcuni problemi ma cambia il modello economico

Cloud Run Instances non sostituisce Cloud Run services, perché rinuncia deliberatamente al principale vantaggio del serverless tradizionale: moltiplicare automaticamente le repliche in funzione delle richieste. La singola istanza diventa invece adatta ad agenti personali, bot, strumenti di sviluppo, piccoli servizi con stato e processi di coordinamento che richiedono continuità senza un’elevata intensità di calcolo. L’indirizzo HTTPS gestito elimina la necessità di esporre direttamente una macchina virtuale, mentre stop e resume permettono di controllare la spesa nei periodi di inattività prolungata. Il prezzo mensile indicato da Google resta però riferito a una configurazione precisa e non comprende necessariamente servizi collegati, storage, traffico o API dei modelli utilizzati dall’agente. Anche il riavvio ogni sette giorni impone di conservare lo stato importante fuori dal file system effimero oppure in volumi montati. La persistenza del servizio non equivale quindi alla persistenza automatica di qualsiasi dato prodotto dal container. OffDeal dichiara di avere ridotto dell’88% i cold start del proprio agente long-running, ma il risultato appartiene a uno specifico workload e non costituisce una garanzia generale. Il significato infrastrutturale è comunque chiaro: Google riconosce che gli agenti non si comportano sempre come normali servizi web. Possono attendere eventi, ricordare configurazioni, mantenere collegamenti e svolgere attività discontinue per conto di una sola persona. Il modello singleton porta questa categoria dentro una piattaforma gestita, evitando di costringere gli sviluppatori a scegliere tra un servizio che scompare quando non riceve richieste e una VM permanentemente accesa. La conseguenza è un serverless meno legato al singolo evento e più vicino alla durata operativa degli agenti, in continuità con gli strumenti che Google Cloud sta costruendo per esecuzione durevole, sandbox e ripristino dei workflow autonomi.

Pythian misura il ritorno dell’AI sui processi e non sulle licenze

L’infrastruttura economica non garantisce da sola un ritorno aziendale. Pythian, società specializzata nei servizi dati, ha utilizzato l’adozione di Gemini Enterprise fra circa 500 dipendenti distribuiti in 27 Paesi come banco di prova per costruire un proprio AI Operating Model. La tesi è che distribuire licenze e misurare minuti risparmiati dai singoli utenti produca micro-efficienze difficili da trasformare in valore strutturale. Il modello descritto nell’analisi pubblicata da Google Cloud e Pythian parte invece da quattro componenti: strategia e governance guidate dal Field CTO, distribuzione sicura degli strumenti, due centri di eccellenza distinti e gestione continuativa della produzione attraverso XOps. Il primo centro si occupa dell’adozione da parte delle persone e costruisce agenti no-code per funzioni come risorse umane e procurement; il secondo sviluppa agenti e workflow personalizzati collegati alle piattaforme dati centrali. Pythian attribuisce soltanto il 20% del percorso al deployment iniziale e l’80% alla manutenzione dell’accuratezza, al controllo della deriva, all’osservabilità e all’aggiornamento dei prompt. Internamente, un flusso applicato a 15.000 ticket mensili dei database legge le richieste, cerca nella knowledge base e prepara mini-runbook prima dell’intervento dell’ingegnere. La società dichiara un aumento di tre volte degli utenti attivi e una riduzione dell’80% nel tempo di risoluzione degli incidenti. In un altro progetto, l’automazione del supporto per 10.000 consulenti avrebbe portato il 10% di 20.000 ticket annuali verso risoluzioni senza intervento umano; nella supply chain, la corrispondenza delle previsioni è scesa da settimane a due o tre giorni per settanta impianti. Sono dati comunicati da Pythian, non benchmark indipendenti, ma mostrano quali metriche debbano accompagnare l’adozione: durata del processo, percentuale di attività autonome, accuratezza e costo operativo nel tempo.

AWS Glue 6.0 porta dati geospaziali e payload variabili dentro Iceberg v3

Sul livello dei dati, AWS Glue 6.0 utilizza Apache Spark 4.1 e amplia il supporto ad Apache Iceberg v3 con tipi nativi che eliminano workaround comuni nei data lake. Le coordinate possono essere archiviate come GEOMETRY e GEOGRAPHY, consentendo l’uso di predicati spaziali come ST_Intersects senza mantenere latitudine e longitudine in colonne numeriche separate. TIMESTAMP_NTZ(9) registra gli eventi con precisione al nanosecondo, necessaria nei flussi nei quali più rilevazioni arrivano nella stessa finestra di microsecondi. Il tipo VARIANT conserva invece payload semi-strutturati con schemi differenti e supporta automatic shredding ed estrazione tipizzata, evitando di appiattire ogni struttura JSON o archiviarla come stringa priva di semantica. Iceberg v3 aggiunge anche valori predefiniti per le colonne.

AWS dimostra le funzioni attraverso una tabella dedicata alla telemetria di una flotta composta da furgoni, biciclette elettriche e robot per le consegne: la posizione viene utilizzata per rilevare violazioni dei geofence, gli eventi distanti un solo nanosecondo restano ordinabili e la stessa colonna variant contiene carburante, batteria, telecamere o cadenza della pedalata secondo il veicolo. Le capacità sono descritte nell’implementazione tecnica di Iceberg v3 su AWS Glue 6.0. Poiché si tratta di caratteristiche del formato tabellare, i dati scritti possono essere letti anche da altri motori compatibili con Iceberg v3 e con gli stessi tipi. Il vantaggio non è soltanto sintattico: ridurre librerie esterne, conversioni e schemi paralleli rende più semplice mantenere pipeline nelle quali geolocalizzazione, eventi ad alta frequenza e telemetria eterogenea convivono. L’aggiornamento approfondisce le funzioni già introdotte quando AWS Glue 6.0 ha completato il supporto a Iceberg v3 e ridotto i costi di elaborazione.

Amazon MQ separa le identità umane dai workload Kubernetes

Amazon MQ affronta un problema diverso ma altrettanto infrastrutturale: consentire allo stesso broker RabbitMQ di riconoscere token emessi da più provider OAuth 2.0. Picnic utilizza RabbitMQ come dorsale fra centinaia di microservizi dedicati a ordini, logistica, consegne e finanza, arrivando nei picchi a quasi un milione di messaggi al secondo. Gli operatori accedono attraverso Keycloak, mentre i workload su Amazon EKS stanno adottando l’autenticazione AWS IAM per eliminare le credenziali statiche.

L’architettura illustrata nell’approfondimento AWS sulla configurazione multi-provider di Amazon MQ associa ogni provider a un resource server e utilizza il claim aud del token per selezionare chi debba verificarne la firma e quali autorizzazioni applicare. I servizi EKS assumono un ruolo IAM, ricevono da AWS STS un token destinato all’audience rabbitmq-iam e lo presentano come password sulla connessione AMQPS. Gli operatori vengono invece reindirizzati a Keycloak, che emette token per rabbitmq-keycloak; i gruppi determinano permessi di sola lettura o amministrativi. Il broker rimane privato dentro Amazon VPC e conserva l’autenticazione interna come accesso di emergenza.

AWS raccomanda di non disabilitare la verifica dell’audience, adottare scope a privilegio minimo e usare token brevi, poiché il plugin OAuth di RabbitMQ non esegue controlli di revoca. I client dovrebbero rinnovare le credenziali intorno al 75% della loro durata, mentre la rotazione delle chiavi richiede una finestra di sovrapposizione nei rispettivi endpoint JWKS. Il modello permette una migrazione progressiva dalle identità tradizionali a quelle dei workload senza costringere persone e servizi ad affidarsi allo stesso sistema di autenticazione.

Continua con:

Google Cloud controlla i costi AI con Spend Caps e Gemini Enterprise

Google AI Studio e BigQuery semplificano sviluppo e analisi sul cloud

Il cloud gestito si adatta a carichi meno uniformi

Cloud Run Instances, il modello operativo di Pythian, Iceberg v3 su Glue e OAuth multi-provider per Amazon MQ mostrano che la maturità del cloud dipende ormai dalla gestione delle eccezioni. Gli agenti personali non seguono sempre il paradigma stateless e richiedono processi singleton persistenti. I progetti AI non producono automaticamente ritorni soltanto perché una licenza è stata distribuita. I data lake devono conservare coordinate, eventi al nanosecondo e payload variabili senza moltiplicare conversioni. Le piattaforme di messaging devono distinguere le identità delle persone da quelle dei workload senza duplicare i broker. Google e AWS rispondono inserendo questa flessibilità nei servizi gestiti, ma mantengono responsabilità precise per chi li utilizza: stato esterno per i container, metriche economiche per gli agenti, compatibilità dei motori per Iceberg e controllo rigoroso di audience, scope e durata dei token per RabbitMQ. Il risultato è un cloud meno uniforme, nel quale serverless, dati e identità vengono adattati alla durata e alla natura reale dei processi invece di obbligare ogni applicazione a seguire lo stesso modello operativo.