Live data from Hacker News

Deploy your side-projects at scale for basically nothing – Google Cloud Run

alexolivier.me

241–250 of 397 posts

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#241

Earlier quoted context omitted.

Cost is not only based on the number of instances. From a quick search: https://www.jhanley.com/google-cloud-run-pricing/ Understanding the cost of these services is not easy at all, especially for extreme cases/situations. And a calculator/estimator won't fix the problem. That is why I love the fixed $X/month where there's no room for surprises.

I hope GCP/AWS add a max spend ability. Until then it's complexity of pricing model vs time spent on OS and database management. To each their own.

The trouble with this is what do you do when your "max spend" is reached? Shut everything down? Shut parts of it down? Most "real world" systems aren't built to have the stool kicked from underneath them like that, so there will be data/business loss and pissed off customers (and in the case of Cloud also pissed off customers' customers).

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#242
post #234

Can't you see this article is a paid advertisement for Google Cloud? Just like those 1 hour long videos on youtube - where they show how pilots fly an airplane of a specific company and how well is al organized or a 1 hour long video of a german car factory. Just reading this line makes you suspicious: "I have built hundreds of side projects over the years " really? Hundreds? And then below: "I am yet to have a side…

similar to that woman who said she was on times person of the year.

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#243

Earlier quoted context omitted.

I have gone serverless for a Vue frontend app I deliver with Cloudflare Workers Sites and with a DigitalOcean S3 Space serving all images. However I'm still very reluctant to use Google Cloud Computing or any similar Azure/AWS solutions for its backend because it just seems pretty expensive to me. I can get a vServer with 48 Gb RAM, 10 vCPUs and a 800 SSD with a 1000 Mbit/s connection and unlimited traffic for 20€ a…

> I can get a vServer with 48 Gb RAM, 10 vCPUs and a 800 SSD with a 1000 Mbit/s connection and unlimited traffic for 20€ a month and run my MariaDB and Redis database on the same machine as my other containers. Where are you getting all that at that price?!

Hetzner has 8 vCPU with 48gb RAM and 2x2TB Enterprise SATA, for 30€ a month with unlimited bandwidth.

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#244
post #103
post #36

Another option is Google Cloud AppEngine. It’s a little more limited in terms of languages that are supported, but the free tier is generous enough that I have never paid anything to run backends for side projects.

For personal projects I think App Engine is superior due to the included services like Mail API and Memcache API. There are also features like Firewall API that's lacking in Cloud Run right now. One downside of App Engine (due to its 10+years of history) is that one GCP project can only have one App Engine app in a single region, and you can't change the region after it's created. You can have arbitrary number of Clo…

Thanks for the insights!

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#245
post #115

Earlier quoted context omitted.

Not sure what happened to your associate but this sounds way, way out there. I run a fairly resource intensive SaaS on AWS (lots of background jobs generating data) and we barely go over $600 a month. People should not be scared of by these anecdotes, however true they may be. It’s perfectly possible to run a very cost effective business on AWS.

It's possible to write bug-free code, but would you bet your financial future on your ability to write bug-free code?

Starting to think the reason we arnt working for google/aws is we make mistakes. Whereas engineers at those companies just dont make mistakes, therefor they assume that billing caps are not necessary. Such is our lot in life.

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#246
post #65

Earlier quoted context omitted.

Disclaimer: I work on Cloud Run as an SRE. Google Cloud has an official deprecation policy. If a product is labeled GA, Google Cloud guarantees that the service will continue running for at least 12 months since the announcement of deprecation.

Exactly. According to what you said, any service with that policy could literally shut down next year if there is a deprecation announcement this year. Which is better than some small no name startup service provider who might just go out of business tomorrow, but among all the big cloud providers Google is definitely the hardest to trust with longevity. A more realistic concern is that Google might substantially cha…

That 12 months is the minimum guaranteed period that your service won't be interrupted.

See the full list of deprecations in App Engine: https://cloud.google.com/appengine/docs/deprecations/

High profile deprecations are handled carefully and we usually handle them with extended deprecation period with clear migration path/doc and communications. Notable examples in the table:

1. Python 2.5: 4+ years 2. Java 6: 20 months with existing user automigrate to Java 7 3. Java 7: 13 months with existing user automigrate to Java 8 4. Master/slave datastore: 3+ years.

Considering App Engine is the first Google Cloud offering, I'd say we have a very good track record of meet our deprecation policy and usually exceeds it.

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#247

I have used it for work-related reasons and indeed the service is quite nice. But I don't use Google Cloud Run for personal projects for two reasons: - No way of limiting the expenses AFAIK. I don't want the possibility of having a huge bill on my name that I cannot pay. This unfortunately applies to other clouds. - The risk of being locked out. For many, many reasons (including the above), you can get locked out of…

> The risk of being locked out.

It is a best-practice to have a GSuite account instead of a consumer-grade Gmail account to manage an associated GCP account.

It is a bit onerous for a hobbyist, admittedly. But if its anything more ambitious than that, do you _really_ want Google scraping the contents of your email while you build the Next Great Thing? Try not to use a consumer account.

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#248

Is anyone familiar with pros/cons vs. AWS ecs? I've used ECS a few times, it's pretty nice. https://aws.amazon.com/ecs/

As others have said, this is like ECS Fargate but scales like Lambda. Very nice offering and I hope it’s lit a fire under Fargate.

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#249

Earlier quoted context omitted.

Is this not typical for...literally every use case? No one has an unlimited budget.

Depends - if your profits increase in line with your expenses, you might be raking in the ad revenue/views/sales/whatever because your product 'went viral' and you might prefer to keep it up. Or if the rise in costs is something you can mitigate on your end - such as a bad deployment - you might want time to respond yourself, rather than your site going offline. More generally, few site reliability engineers are look…

> few site reliability engineers are looking to add extra ways for the site to be taken offline

If your company has anything close to "reliability engineers", then you already have legal and finance teams too that can sort terms out.

The discussion is about companies that do not even have departments to begin with.

Re: Deploy your side-projects at scale for basically nothing – Google Cloud Run

#250

Earlier quoted context omitted.

Definitely something I look out for, but the advantage over something like Cloud Functions, which would be an alternative, is that a Cloud Run service handles multiple requests per instance so it isn't 1:1 with request rate.

Cloud Functions isn't 1:1 IIRC, once a Function is booted it keeps serving more requests once warm.

No, the concurrency of GCF is always 1. If the latency of your code handling request is 1s, to handle 100 requests per second you'll need to have 100 instances running.
Post reply on HN