Google Cloud gør infrastrukturen klar til altid aktive AI-agenter

I august lancerede Google Cloud to komplementære byggesten til AI-agenter, der skal kunne arbejde døgnet rundt: Database Operations Agents til automatisering af databaseopsætning og -drift samt Cloud Run-instanser til billige, vedvarende kørsler af enkeltstående agenter. Tilsammen udvider de Googles strategi for Agentic Data Cloud fra selve datahåndteringen til den driftsinfrastruktur, som agenterne er afhængige af. 78

Database Operations Agents: fra opsætning til fejlsøgning

Den Gemini Cloud Assist-integrerede løsning består af to agenter:

• Database Onboarding Agent håndterer Day 0-opgaver – valg af database, opsætning, konfiguration og den første udrulning.
• Database Observability Agent tager sig af Day 1- og Day 2-opgaver som overvågning, fejlsøgning og løbende vedligeholdelse. 8

Målet er at erstatte en del af det gentagne arbejde med arkitekturplanlægning, scripts, klargøring, skema- og indekskonfiguration, tuning af forespørgsler og diagnosticering med guidede arbejdsgange i naturligt sprog. Det kan reducere manuelt arbejde for databaseadministratorer, udviklere, SRE-teams og DevOps-medarbejdere. 8

Onboarding Agent guider brugeren gennem klargøring og grundkonfiguration af Googles administrerede databaser AlloyDB, Bigtable, Cloud SQL og Spanner. 8

Observability Agent samler og sammenholder telemetri fra blandt andet Database Insights, Cloud Monitoring, Cloud Logging og Cloud Trace. På den måde forsøger den at finde den underliggende årsag til problemer som pludselige latenstoppe, belastede forespørgsler, låsekonflikter og begrænsede ressourcer. 8

Forslag til ændringer – og mulighed for at udføre dem

Agenterne er tilgængelige gennem flere af Googles og udviklernes værktøjer: Gemini Cloud Assist-chatten, relevante databasesider i Google Cloud-konsollen, Database Center-visninger på tværs af databaser, kommandolinjen, IDE’er og tredjepartsværktøjer. 8

Database Insights og Database Center kan desuden bruges som MCP-værktøjer via Googles Remote MCP-servere. Det giver eksterne udviklerværktøjer og agenter adgang til blandt andet system- og forespørgselsmålinger, inventar over databaser og registrerede problemer. 8

Løsningen nøjes ikke med at stille en diagnose. Den kan foreslå validerede ændringer, forklare begrundelsen og beskrive den forventede effekt. Hvis brugeren godkender det, kan den også udføre understøttede afhjælpninger – for eksempel aktivere forbindelsespooling i Cloud SQL eller tilføje et indeks. Visse funktioner til undersøgelse og afhjælpning var dog stadig i preview for udvalgte kunder. 8

Cloud Run-instanser til vedvarende agentkørsel

Den 27. august introducerede Google Cloud Run-instanser i preview. Det er dedikerede, enkeltstående Cloud Run-runtime-miljøer til langvarige og tilstandsbevidste arbejdsbelastninger – typisk agenter, der kun bruges af én bruger. 9

I modsætning til almindelige Cloud Run-tjenester gælder det, at en instans:

• kører præcis én kopi uden autoskalering
• ikke skalerer til nul
• kan køre kontinuerligt i op til syv dage med automatisk genstart
• kan stoppes og startes igen
• får en stabil HTTPS-adresse, som ikke ændres ved opdateringer eller genstarter. 9

Google positionerer funktionen som et alternativ til en virtuelt maskine, der står tændt hele tiden. Brugeren slipper dermed for vedligeholdelse af et operativsystem samt opsætning af firewall og HTTPS-endpoint, men får stadig en vedvarende procesmodel, som traditionelle serverless-tjenester med skalering til nul ikke tilbyder. 9

Google oplyser en pris på 5,70 dollar for 30 dages kontinuerlig kørsel med 1 shared vCPU og 1 GiB hukommelse. Modellen bruger burst-budgetter til lejlighedsvise beregningstoppe i stedet for, at man hele tiden dimensionerer og betaler for en fuld VM. 9

Vedvarende kørsel kan også mindske eksponeringen for cold starts. En tidlig bruger har eksempelvis oplyst, at cold starts for dennes langvarige agent faldt med 88 procent. Det er dog en kundeerfaring og ikke en generel garanti for alle arbejdsbelastninger. 9

Google forsøger at løse begge sider af agentinfrastrukturen

AI-agenter har brug for en billig og stabil måde at køre på, især når de skal koordinere asynkrone opgaver eller håndtere samtaler over flere interaktioner. Samtidig skal de databaser, agenterne arbejder med, kunne klargøres, overvåges og fejlsøges uden lige så meget manuelt driftsarbejde.

Cloud Run-instanser adresserer den første udfordring, mens Database Operations Agents forsøger at gøre datalaget mere tilgængeligt gennem naturligt sprog og MCP-kompatible værktøjer. Det er dermed et skridt fra blot at bruge AI-agenter til også at automatisere den infrastruktur, de afhænger af. 18

Der er dog en vigtig begrænsning: En runtime, der beskrives som tilstandsbevidst, gør ikke automatisk agentens data holdbare. Hvis en agent skal kunne overleve genstarter eller bevare igangværende arbejde længere end runtime-miljøets levetid, kræves der stadig ekstern, persistent lagring. Googles egen vejledning peger blandt andet på persistent sessionslagring som Cloud SQL til produktionsagenter. 5