I'm looking for something like that, but I'm afraid of using any google developer services, such as GCP, for personal projects. What if I breach their TOS somehow and get banned, or what if I didn't breach their TOS and still get banned?
Can't afford to test my luck until I've finished migrating all my accounts off my gmail.
I'd also need a new credit card, I'm pretty sure they link accounts via shared CC. And even then, I'm pretty sure they still link accounts via other means. Did I link my gcp email in my android gmail app? Did I use the same IP address for both accounts? Or any of the thousand ways google has to know two accounts belong to the same person.
Honestly, creating a second google account might itself increase the chances of getting banned. Nobody knows with Google, and that's the problem.
I'm using my main google account on GCP and just yesterday started to take precautions about this.
I created a new google account with no relation to my main one and added it as an owner to my GCP project, so hopefully in the event of either account being banned I can still access everything.
Cloud run is great. I'm using an Nginx image to serve my static website. However, if I remember correctly, you can only respond to HTTP(S). So though it may be enough for most usecases, it is not essentially equal to running any container on the cloud.
Websockets now work on cloud run. We implemented that last month. Cloud run does have a few limitations: no service discovery built in, no docker compose support, limited set options for CPU/memory, no persistent disk, etc. But it's great for things like a simple Spring Boot server or any kind of stateless service. But you won't be running redis or a database there. It's just not designed to do that. It's also not great for running batch jobs; we tried and our jobs kept getting killed/throttled. Use a vm for that.
Luckily, there are lots of other Google services for that that you can plugin for that sort of stuff. Cloudrun is great if you are planning to use those things.
Kubernetes is what you use when you want to mix stateful and stateless stuff so you can avoid depending on those services. That makes sense if you need to support multiple clouds or on premise installations. But otherwise, it's a lot of extra complexity and devops even before you consider the overhead of managing the kubernetes cluster. There are lots of companies that talk themselves into needing this where the need is arguably a bit aspirational. I've been on more than one expensive project where we served absolutely no traffic at all with hundreds of dollars worth of kubernetes clusters idling for months on end that had no realistic hopes of ever getting more than a very modest amount of traffic even if everything worked out as they planned.
You can open just 1 https port but you can map whatever port in your docker container to that. Some websocket implementations work with a second port and that just doesn't work. But you should probably split those services into two. But if you use something that can mix websockets and normal https traffic over 1 port, it works great.
For my usage (lightweight game servers), I need WebSockets, which are still in beta and they currently force WS connections to close after 1 hour, which is a dealbreaker for me.
Dokku looks super cool but it's still a lot more involved than Heroku. Heroku doesn't make you think about provisioning servers, updating infrastructure, or manually setting up common integrations like backups and logging.
Just to illustrate the point, dokku's docs[0] for logging say "Warning: The default docker-local scheduler will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server."
Alright, well, that's gonna be a whole lot more work than two click in Heroku to send all my logs to any logging provider of my choice.
