Cloud Run GA: migrate App Engine Java standard images to containers; BigQuery adds Gemini Flash integrations

Cloud Run just removed one of the messiest parts of App Engine->container migrations: you can now migrate Java standard environment images into Cloud Run as a generally available feature, without rebuilding app images by hand. That change will shave weeks off many brownfield modernization projects.

Google's announcement isn't just a checkbox for lift-and-shift. The migration path preserves App Engine image artifacts and provides automated compatibility checks, which means platform teams can treat many Java standard apps as first-class container workloads immediately then iterate on refactorings and runtime improvements on the other side. Pair that with the Cloud Run tooling for moving Functions and App Engine workloads into containers reaching GA and you get a coherent, auditable path from older serverless runtimes to one managed container runtime for HTTP and event-driven workloads.

This is the right call. The alternative forcing teams to rebuild legacy images into containers or rewrite runtimes was a slow, high-risk path that left many services on App Engine longer than they should be. Cloud Run's move recognizes that modernization is often incremental: preserve behavior first, modernize architecture later.

But while Google is lowering the friction for migrating compute, it's also shifting how AI and analytics are packaged. Google has broadened availability of lower-latency "Flash" variants of Gemini models inside its Gemini API and Google Cloud offerings, and BigQuery now supports Gemini model integrations for in-database generative capabilities across major regions. Google has also announced introductory pricing/promotional windows for some of these model options.

Here's the rub: Google is adjusting the availability of some advanced graph processing features in BigQuery toward higher-tier editions. In plain terms, certain built-in graph primitives and tightly-coupled graph workflows will be limited to Enterprise/Enterprise Plus SKUs or equivalent paid tiers. That moves advanced analytics patterns traversals, recommendations, and network analysis behind a higher price and a different procurement conversation.

This is a monetization play dressed as product segmentation. The technical implication is immediate: teams that relied on BigQuery's built-in graph functions will either need to upgrade to higher BigQuery SKUs, rework pipelines into custom graph engines, or move parts of their analytics stack outside BigQuery. None of those are free. It's also a signal that Google expects more LLM inference to run inside BigQuery rather than in separate model runtimes.

Operationally there are a handful of platform-level changes platform engineers need to add to runbooks:

Cloud Storage can retain soft-deleted buckets or objects for a configurable retention window after project or resource deletion in some scenarios. Accidental deletions are harder to make permanent; audit retention windows to avoid unexpected storage costs.
App Engine now defaults to TLS 1.2+ for client connections; older TLS versions are deprecated and should be remediated if still in use.
Backup & DR tooling can apply project-level Resource Manager liens with optional multi-party approval flows. That helps prevent destructive automation but can break naive destroy pipelines that expect immediate project deletion.

Two clear actions for platform teams: inventory and staging. Inventory which Java standard apps you can push to Cloud Run with minimal change, and stage migrations to capture quick wins. Simultaneously, catalog any BigQuery workloads that use graph functions and plan whether they belong on an Enterprise SKU, on an external graph engine, or in an AI-first refactor that leverages integrated Gemini model support.

Google's strategy here is two-headed: make it effortless to bring legacy compute into a modern managed runtime while converting analytics demand into a revenue stream via integrated AI. That's not inherently bad tighter integration often yields faster developer velocity but it will change cost and architecture conversations. If you're a platform engineer responsible for modernization and analytics, pick your battle: move compute to Cloud Run and accept vendor-managed AI in BigQuery, or keep inference and graph processing in your stack to avoid downstream lock-in.

Either way, this week makes one thing clear: migrations are no longer the slowest part the pricing and edition decisions around AI will be. If you haven't mapped where your BigQuery graph workloads and LLM inference live, this is the moment to do it.

Cloud Run GA: migrate App Engine Java standard images to containers; BigQuery adds Gemini Flash integrations

Sources

Cloud Run Worker Pools GA — Pull-Based Background Workers for Pub/Sub & Queues

Gemini Flash GA: Gemini API, Enterprise Agent Platform, and BigQuery in-database inference

GKE 1.36: Autopilot Arm ComputeClasses (autopilot-arm, autopilot-arm-spot) for mixed Arm/x86 clusters