I migrated my screenshot API project to Google Cloud.

My main reason is that I want peace of mind with my infrastructure for an extended period of time. And I want to concentrate solely on customer support, marketing, and selling, not on scaling issues and other technical matters.

If you are curious about the details, I am sharing a short story about my infrastructure journey and plans for the future.

MVP on DigitalOcean with 2 droplets

Truthfully, I started from MVP on DigitalOcean with 2 droplets (VPS), one for the dashboard and one for rendering screenshots.

It was enough to test the product and launch, but after users started to sign up and use the API, scaling issues arose, and I needed to act quickly. I had many options to choose from:

• Scale the droplet vertically (increase CPU and RAM).
• Add one more droplet and load balancer.
• Set up Kubernetes cluster with autoscaling.
• Move to Render or other services that can quickly spin up Docker containers and support autoscaling.
• Buy powerful cheap servers or VPS to handle all the load I have in one or two instances.
• Using AWS Lambda functions or Google Cloud Run or functions.
• And many other options.

But I didn’t have time even to think. I needed a solution quickly. Kubernetes looked like the best choice then, but I didn’t have experience setting it up. I worked only as a developer with Kubernetes.

I had an experience with AWS, but not with AWS Lambda.

So, I decided to move to Render.

Moving to Render as a quick solution

Moving to Render was easy. I needed to link my GitHub repository and choose the plan (means resources). Then in 2 clicks, I set up autoscaling. And it helped me to survive for a long time. At least 2-3 months.

But then, new requirements and use cases arose, which Render couldn’t handle for me. I needed to spin up a new service instance immediately upon request, not on an average load of the instances I had.

Some customers can send 6-20 requests in a batch simultaneously. Render’s load balancer distributes the load among instances evenly. But if I have 2 instances and 20 requests received simultaneously, it will split the batch by 10 requests each and send them to instances. And then spin up new instances which won’t process these requests and will just idle.

The easy solution is to have more instances in the pool available. And it won’t be a problem for me. But to process requests, I needed at least 8 GB of RAM. And that’s when it becomes too costly with Render.

I loved Render’s UI and support. Would it be cheaper? I won’t move away.

So, I started looking for other solutions. My limitations were time to migrate, obviously money, and to support new requirements to handle immediate bursts of load.

Trying Google Cloud Run

I started exploring AWS Lambda functions, Google Cloud Functions, and Google Cloud Run. Since I haven’t used Google Cloud before, I was eligible to use $300 in credits for 3 months. I decided it was a reasonable time period to test the cloud and estimate my costs and overall experience.

It took me 4 hours to deploy the service to Google Cloud Run with a straightforward command—gcloud deploy. For another 2 days, I spent on a solution to move my custom domain from Render to GCP without downtime. But it was costly in terms of time and nearly impossible, so I found the time slot when my servers were idle, and nobody used them and migrated my domain.

Why Run and not Functions?

I haven’t tried GCP functions, but GCP Run looked like a good fit. It can immediately spin up new containers to handle requests and reuse containers. And I pay only when my containers are running.

With such a configuration, I felt I could have a piece of mind for long periods.

Once the trial approaches the end, I will evaluate the costs and usability of the cloud and decide what to do next.

Why I share my infrastructure journey

Frankly, from the inside, it is hard to understand what I am doing wrong or if I do effectively what I do. But many brilliant minds can look at what you do and share many ideas on what can be done better, cheaper, more effective, and so on.

I would love to hear your thoughts, and thanks for reading.