📦 Moving from Heroku to Google Cloud - but how?
As Yomi.ai is growing (and got accepted into Google Cloud for Startups), I'm thinking of moving away from Heroku to GCP.
The main pieces are the http(s) server and the Postgres database.
The API is written in Rust. On Heroku I use a rust buildpack and a git push sets off the deployment. No need to dockerize anything on my part, which I'm perfectly fine with. On startup, the server also does some internal processing before accepting requests. Furthermore, since I use stripe for subscriptions, I have a webhook that needs pretty much instant returns.
Would this disqualify Google Cloud Run, because there are very quiet times and the service could be shut down to 0? I could probably solve this by adding a queue, but at this point in time, I'm not too willing to overcomplicate things nor spend too much time on restructuring infrastructure.
What would Heroku's replacement of the dyno be? Google App Engine?
Switching out Postgres seems to be more straightforward with Google SQL. But I'm not looking forward to the data migration. Any advice would be greatly appreciated.
Update: I have completed moving Postgres to Google Cloud SQL with no downtime.
AFAIK Cloud Run + Cloud build is the closest thing to Heroku.
You can always go "low-tech" and just use Compute Engine
Sounds good. However, I have trouble containerizing my API right now: https://stackoverflow.com/questions/62745830/standard-init-linux-go219-exec-user-process-caused-no-such-file-or-directory
Just as @gnilly said, probably it's desired to go for the Compute Engine and host your app on cloud VMs. As you scale is important to have more and more control over your resources (and costs) so that you can properly secure, monitor and customize.
For the database migration, I would say it shouldn't take too much using pg_dump and pg_restore. At most an hour if you have a lot of data, which I think is acceptable in low traffic periods (such as weekend nights). But make sure your clients will be aware of the maintenance/migration window.
If you change cloud providers and you are dependent on some features those providers offer, I'm afraid you can't switch from one another without investing time and resources in tooling rewriting. This is commonly referred as "vendor lock-in".
To avoid this, I always pack my services in docker containers, run them either in kubernetes or on instances with docker-engine installed, and then any migration is just a matter of running the same docker images on another server, switching traffic to the new servers and turning off the old containers. With dockerized applications, vendors can't really to that much to lock you in.
As a heavy Heroku user for as long as I can remember, it amazes me that it's a platform that continues to provide terrific value even when all the other cloud services had years to attempt to catch up.
Sure it might be a bit expensive at face value, but in terms of a developers ability to deploy code without having to worry about, or spend any time on, any type of "DevOps" is incredible. I've done lots of larger scale deployments, and I really can't find any better alternative to just pushing your code to Heroku and spinning up a dyno.