The Dev World – Sergio Lema

I recently created a Google Cloud Function to execute some code once per week. Instead of cluttering my backend with additional dependencies, I figured a serverless function would be a cleaner solution.

It seemed like a brilliant idea or at least a smart idea, until reality hit me.

Context

What I wanted to deploy in the Cloud Function was straightforward: read some data from the database, update a few rows, and call it once per week.

The main reason for offloading this process to a Cloud Function was to keep my backend clean, as it didn’t need the extra dependencies required for this specific job.

The plan was simple, elegant, but naive.

The Problem

Since my function needs to read and update database records, it naturally has to connect to an SQL instance. You’d think that’s a simple requirement: just open a connection, execute a query, and be done.

But no, Google Cloud Platform (GCP) had other plans.

Why is this complicated? Imagine a high-traffic workload where hundreds of Cloud Functions spin up every minute, each opening its own database connection. That’s a one-way ticket to connection pool exhaustion, which would send my database into a well-deserved coma.

GCP prevents this disaster by not allowing direct SQL connections from Cloud Functions. Instead, they suggest a proxy.

The Proxy

So, the proxy is called the Serverless VPC Access, an always-on instance (or multiple instances, depending on your workload) that acts as a middleman between the Cloud Functions and the database.

Instead of each function connecting directly, they all go through the proxy, which then communicates with the database. It’s a great idea, if you enjoy paying for a virtual machine running 24/7 just to keep your serverless function functional.

So, let me get this straight: I used Cloud Functions to avoid upgrading my backend instance and incurring extra costs, only to find out that I now need to spin up another instance just to act as a proxy? Perfect.

My Solution

It turns out I was using Cloud Functions for the wrong purpose. They shine in handling massive workloads with unpredictable spikes, not in managing infrequent, scheduled tasks.

After some deliberation (and a few choice words), I decided to move the logic back into my backend and simply hope that my instance doesn’t need an upgrade.

Because if there’s one thing I love more than well-architected solutions, it’s fearing to open the cloud bills.

Conclusion

This whole ordeal has me seriously considering a move to AWS, where I could use AWS Lambda with direct database access (no proxy required). Sure, they recommend a database proxy for high workloads, but at least I have the option to skip it.

GCP, on the other hand, is like that overprotective parent who refuses to let you make your own mistakes. Sometimes, I just want to take my database connection, live dangerously, and see what happens. But hey, that’s just me.