Kubernetes to Cloud Run — and why it was the right call

The platform decision came from the workload, not the other way round. Cloud Run fit for three specific and checkable reasons: the services were already containerized, they were stateless, and they communicated over HTTP. Those three properties are exactly what a request-driven serverless container platform is built for, and they were already true — which meant the migration was a change of venue rather than a rewrite. The application code remained almost entirely untouched; what changed was where it ran. Nothing about the move required the team to adopt a new framework, restructure the services, or take on a migration project that would outlast the savings it produced. The reasoning generalizes: the best architecture is not the most advanced one available, it is the one that matches the shape of the workload in front of you, and a cluster orchestrating one pod per service is a mismatch no amount of tuning will fix.

Environments were tuned separately, because they have different jobs. The three production services were deployed to Cloud Run with a minimum instance count of one. That keeps a warm container resident at all times, which means cold starts never reach a user and the perceived performance of the product is unchanged from the cluster it replaced — the point of the exercise was to cut cost, not to quietly trade it for latency. Development and sandbox environments were configured the opposite way, with minimum instances set to zero. When nobody is using them they simply disappear: no running containers, no idle CPU, no charge. This single split is where a large share of the saving comes from, because those environments had previously been billed continuously for capacity that went unused most of the week.

A concurrency problem surfaced, and the fix was counterintuitive. Shortly after the move, the backend started behaving oddly: under a light load of logins, Cloud Run would spin up three and sometimes four containers almost immediately, despite utilization being nowhere near a level that warranted it. The cause turned out to be the CPU allocation. At 0.5 vCPU, Cloud Run does not allow request concurrency to be configured the way it does at 1 vCPU, so each instance was effectively handling very few concurrent requests and the platform was compensating by scaling out horizontally. Raising the backend to 1 vCPU and setting an appropriate concurrency value fixed it: a single container then handled multiple simultaneous login requests exactly as expected. The lesson is worth stating plainly — allocating less CPU is not automatically cheaper, because an under-provisioned instance can force the platform to run several of them where one properly sized instance would have done.

The ingress path was rebuilt in layers rather than lifted across. Traffic now passes through several independent filters before it reaches any application code. Cloudflare sits at the edge and provides automatic HTTPS, TLS termination, DDoS mitigation, a web application firewall, rate limiting, bot protection, DNS proxying, origin IP hiding, and IP reputation filtering — a substantial amount of protection that arrives essentially for free. Behind it, a Google Cloud Load Balancer acts as the single entry point into the platform, and Cloud Armor is configured to accept requests only from Cloudflare's published IP ranges, which closes the obvious hole of an attacker discovering the origin and going around the edge entirely. The Cloud Run services themselves are not publicly accessible at all; they only ever receive requests from the load balancer. Each layer is independently useful, and a request has to satisfy all of them.

Database connectivity moved to Direct VPC Egress. Reaching Cloud SQL privately from a serverless platform traditionally meant a Serverless VPC Access Connector, which quietly runs its own always-on connector VMs and bills for them regardless of traffic — precisely the kind of idle cost the migration existed to remove. Direct VPC Egress replaces it: Google charges only for the network traffic itself, there are no permanently running connector instances to pay for, and it delivers roughly twice the throughput of the legacy connector. Cloud Run containers now talk to Cloud SQL entirely over Google's private network, and the database has no public endpoint at all. It is a rare change that improves cost, throughput, and security simultaneously, and it removed the last always-on component from the architecture.

What was left over was operational simplicity. With the worker nodes gone, an entire category of recurring work disappeared with them: no Kubernetes version upgrades to schedule and test, no node pools to size or drain, no cluster capacity planning to revisit as the product changed. The architecture ended up with meaningfully fewer moving pieces than it started with, which makes it easier to reason about and easier to operate day to day. That is the part that does not show up on an invoice but tends to matter most over a year — the same three services, doing the same work, on a platform that asks far less of the people maintaining it.