
Cloud Run beta pricing - rahimnathwani
https://cloud.google.com/run/pricing
======
WestCoastJustin
This might be a better link:
[https://cloud.google.com/run/docs/](https://cloud.google.com/run/docs/)

" _Cloud Run is a managed compute platform that enables you to run stateless
containers that are invocable via HTTP requests. Cloud Run is serverless: it
abstracts away all infrastructure management, so you can focus on what matters
most — building great applications. It is built from Knative, letting you
choose to run your containers either fully managed with Cloud Run, or in your
Google Kubernetes Engine cluster with Cloud Run on GKE._ ".

So, like lambda but with containers. Pretty much what I have wanted since I
first started learning about Docker.

~~~
nilkn
This seems like a competitor more to Fargate than to Lambda, right?

~~~
ilogik
With Fargate you have containers running all the time, and you pay for
that....from what I've seen of Cloud Run, you just pay when you're actually
serving requests

~~~
asciimike
With Cloud Run you're only paying for resources used, and with Cloud Run on
GKE you're paying for the underlying cluster [1]. This also gives you the
flexibility to optimize costs by shifting workloads between the two if
desired.

[1]
[https://cloud.google.com/run/pricing](https://cloud.google.com/run/pricing)

------
steren
Hi, I'm a product manager on Cloud Run. Thanks for your enthusiasm and
feedback. We are very excited to share this new product with you. The reason
we remain silent at the moment is because Cloud Run will officially be
announced at 9am PST tomorrow during Google Cloud Next 2019. We will publish a
blog post and other material that should answer many of your questions. We
look forward to hearing what you think about it and what you'll build with
Cloud Run.

~~~
pfarnsworth
Will Google guarantee a minimum number of years to support this platform? I
would hate to dedicate time and resources to this (sounds pretty useful) and
then have Google shut this down in the near future.

~~~
mattsoldo
Hi. I manage App Engine (the original "serverless" product at Google).

This is a very understandable concern, given the importance of having a
platform on which you can rely.

Contractually Google Cloud provides a 1 year notice before discontinuing (or
making backwards incompatible changes) to products. This is for generally
available (GA) products. Cloud Run is in beta, so technically it could be
decided not to bring it to GA. This is why some conservative orgs tend to wait
for products to be GA before releasing them.

From a technical perspective, Cloud Run was designed to be highly portable and
idiomatic. If the service were discontinued (or you just didn't like it), you
should be able to take your container image, and run it anywhere else. Odds
are you would be using some other Google Cloud Services, so you would likely
want to run in an environment with low network latency to Google Cloud
(Compute Engine and Kubernetes Engine being obvious candidates).

From a historical perspective, I'd say that Google Cloud goes above and beyond
in supporting older products. App Engine is about to hit its 11th anniversary.
We are still running PHP 5.5 apps and backporting security patches to the
runtime, despite the language losing community support 3 years ago. We are
still turning down an old product called "Managed Virtual Machines", which has
now been in a deprecated (but running) state for longer than it was GA!

From an emotional perspective, I think that Google is eyed with a lot of
suspicion for turning off products. Google Reader - enough said. But as
someone on the thread pointed out, Google Cloud is a very different business
from the rest of Google. Google (!cloud) is a consumer company at a scale
where if a product matters when it hits a billion users. Google Cloud is an
enterprise company. Scale still matters, but not in the same way it does in
consumer.

I can't wait for hacker news folks to try Cloud Run. Its an awesome product.

~~~
clhodapp
_Cloud Run is in beta, so technically it could be decided not to bring it to
GA. This is why some conservative orgs tend to wait for products to be GA
before releasing them._

Ah that's _one_ reason not to use GCP betas. Another big one is the complete
lack of any public uptime target. In my opinion, this makes the betas nearly
as bad as alphas with respect to using them in production.

~~~
boulos
Disclosure: I work on Google Cloud.

That's precisely the point: don't use Betas in production, unless you're okay
with that. Do you have a suggestion on wording for the help text to reiterate
that more clearly?

The background here is that a Beta product is still in flux. In particular, it
might not be GA yet because it hasn't yet met its internal SLO for enough
time, proving that it can consistently meet the SLO for its SLA.

While we could let products ship randomly, since SLAs "just" mean we pay you
if we don't meet them, we choose not to. Customers expect that if a product
says "this is our SLO/SLA" that we intend to hit that.

We hear you though; we don't like super long Beta durations any more than you
do. Sometimes though, we reached Beta and didn't realize we hadn't met the
quality bar we wanted.

------
euph0ria
There are two reasons why our company will not use Cloud Run, even though we
would love to, the concept is just what we are looking for for our containers:

1) We are on AWS and expanding to Google is too expensive. Support costs for
three engineers to be able to contact Google is $750/month for production
workloads. At AWS we pay $200/month as our total spend on infra is about
$2000/month. We are a startup with a tight budget, hence the increased spend
is too tough to swallow even though we would love to use Cloud Run.

2) We have an Android app. Having seen how other companies have been hell-
banned and shut down from having invited devs and other with flagged accounts
we just don't dare to use Google Cloud while having an Android app should we
end up on the automatic hell ban list at Google. Too risky.

~~~
asciimike
Is there a reason you can't/wouldn't want to use Knative? Or what if you can
run something like "Cloud Run on GKE on AWS" (where your GKE cluster is
managed [updated] by Google but running on AWS)?

~~~
euph0ria
Sure, we could, but I suppose one of the big offers here is that it is managed
and we don't have to deal with running it ourselves. GKE on AWS doesn't solve
my (1,2) concerns.

------
johne20
Am I reading pricing right, that it is $0.40/million requests beyond free
quota versus $3.50/million (first 333 million) on AWS API Gateway? One thing
that always killed AWS Lambda/APIG for our use cases was the API Gateway
request pricing. This seems much better.

I love that you can just run Docker containers. My one wish is the option to
run on multiple regions at once with Anycast or similar.

I haven't tested yet to see what extra latency or cold start times this may
have. That is the other thing that bothers me about Lambda.

~~~
asciimike
> that it is $0.40/million requests beyond free quota versus $3.50/million
> (first 333 million) on AWS API Gateway

Comparing Run to API Gateway is a bit apples to oranges, as one is a managed
compute product and the other is an API management product.

Run (and GCF, and GAE) automatically provision an HTTP endpoint for you so you
aren't _required_ to use an API management product like Cloud Endpoints.
However, they don't provide API key validation, rate limiting/quota, schema
validation, etc. which is what you're paying for (even if you're not using
them) with API Gateway.

A more apples to apples comparison would be something like: \- Cloud Run
($0.40/M) + Cloud Endpoints ($3.00/M) = $3.40/M \- Lambda ($0.20/M) + API
Gateway ($3.50/M) = $3.70/M

> My one wish is the option to run on multiple regions at once with Anycast or
> similar.

We're working on GCLB ([https://cloud.google.com/load-
balancing/](https://cloud.google.com/load-balancing/)) integration, which will
let you create multi-regional or global service.

~~~
johne20
Thank you for your response, that definitely helps me understand the
differences.

In our particular higher volume use cases, we handle the rate limiting/key
validation ourselves so I like that Run automatically provisions a HTTP
endpoint.

------
minimaxir
Right now, I run ad hoc containers/bots cheaply on GCP by using Cloud
Scheduler to turn on a preemptible VM which invokes a Docker container, run a
function, and immediately shut it down. (technical details here:
[https://minimaxir.com/2018/11/cheap-
cron/](https://minimaxir.com/2018/11/cheap-cron/))

Cloud Run seems to obsolete that workflow (and it fits well within the free
tier), and I couldn't be happier. Will watch the keynote tomorrow for more!

~~~
ec109685
You could run gke on preemptible VM’s and this on that:
[https://cloud.google.com/kubernetes-engine/docs/how-
to/preem...](https://cloud.google.com/kubernetes-engine/docs/how-
to/preemptible-vms)

~~~
minimaxir
I talk about that in the article; you can't scale down to 0 nodes in GKE so
it's still more expensive. (it _may_ be possible although not easy:
[https://stackoverflow.com/questions/51655781/google-cloud-
ku...](https://stackoverflow.com/questions/51655781/google-cloud-kubernetes-
cost-when-rescaled-to-0-nodes))

~~~
ec109685
Good points.

------
lukecameron
I think this has the potential to be huge. Finally a FaaS platform without
vendor lock-in, supported by a major cloud vendor, and uses regular
containers. Basically removes all of the major drawbacks to move to serverless
(for applications that suit the FaaS model).

~~~
everdev
> Basically removes all of the major drawbacks to move to serverless

What about cold starts, debugging and runaway expenses?

~~~
lukecameron
Since the technology is based on knative, it should in theory be possible to
run these on a local k8s instance. It would support some debugging use cases.

I do agree as far as cold starts and runaway expenses go, although those
issues seem inherent with FaaS.

~~~
kortilla
The biggest issue isn’t being able to run locally, it’s getting access to
systems where an unexpected error is happening in production that didn’t
happen in dev.

------
revskill
Finally, this is what a developer really wants.

Vendor lock-in is bad in general, whatever awesome it is.

I think this is a great move, which teaches other companies remove lock-in
from their products.

Never force devs to follow you, follow devs instead.

------
perttie
Took a test run using gcr.io/cloudrun/hello-image with 128Mb memory and 80
concurrency: cold response about 450ms, warm 2-5ms (as reported by logging).
Scaling seems to work, got about 200 requests/s with quick ab-testing. Domain
name mapping + HTTPS is nice addition.

Price-point: using 128Mb+100ms "defaults" from other serverless pushes price
over $3/million requests. If any concurrent requests going, price/request goes
under $1/million. And don't forget network prices, hello-image return a bit
over 4kB so that means $0.46/million requests.

Biggest concern is overall latency, from EU I got 1020-1300ms total latencies.
Tracerouting address gives 60ms "ping" latency. And sometimes total latency is
220-250ms (less than 10% requests). This really needs some inspecting.
Otherwise pretty nice service, I have been waiting something like this :)

~~~
ngrilly
About latency from EU, it's not possible to choose the deployment zone?

~~~
perttie
While in beta, us-central1 is only region

~~~
ngrilly
Thanks. Makes it useless for me right now then :-)

~~~
asciimike
We're working on adding new regions in the near future, so stay tuned!

~~~
ngrilly
Great! Is Cloud Run positioned as a possible replacement for App Engine?

------
etaioinshrdlu
So is this basically App Engine Flexible Environment with a quirk that it
pauses (freezes for later thawing) your container (like GCF or AWS lambda)
when not handling a request?

Would be good to see more info like concurrency limits (80 mentioned in the
quota is super low...) and cold start times. Things that affect how useful or
not useful this is for handling large bursts.

~~~
teraflop
> Would be good to see more info like concurrency limits (80 mentioned in the
> quota is super low...)

That's 80 concurrent requests _per container_.

~~~
ec109685
Versus 1 on Lambda.

------
taesis
This looks like Azure Container Instances [1], but on GCP. Does that sound
about right?

[1]: [https://azure.microsoft.com/en-ca/services/container-
instanc...](https://azure.microsoft.com/en-ca/services/container-instances/)

~~~
tgtweak
Yes but initiated (and automatically suspended) based on a web request.
Azure's is from (and billed from) container pull start until terminated (by
you).

~~~
taesis
Aah, thanks for the clarification :) the top voted comments on this article
now indicate that as well, so hopefully no one else will have the same
confusion.

------
rjhacks
How much CPU is allocated to a Cloud Run (not-on-GKE) instance while a request
is active? I see that memory is configurable (up to 2G), but no word about
CPU...

I have a compute-heavy and bursty workload that I'd _love_ to put on Cloud
Run, but it's important to know a ballpark for the CPU I'll get to spend on my
requests.

Second question: any plans to more officially support "background" workloads
that consume off e.g. Pub/Sub and might be able to use cheaper preemptible
compute? I guess I'm probably already able to point a Pub/Sub push queue at a
Cloud Run endpoint, but having the option of cheaper (autoscale-to-zero)
compute for my not-latency-sensitive work would be awesome.

~~~
hiroshi3110
I’v been using cloud build for background tasks. You may need to write a
function triggered by pub/sub and submit a cloud build though.

------
mpalmer
I think the tech that allows Google to measure the use of its infrastructure
in the way they're doing here might be a part of the strategy for Stadia
(stadia.google.com). Pricing info was conspicuously missing from Google's
Stadia introduction, and I've been wondering if Google's use-based cloud
billing model could work if it were just passed on to the user - bill the user
(or player) to the minute or even to the second.

Deals could be structured so publishers get a cut of fees that are tied how
long players want to play the game. Billing individual seconds of gameplay
would be a radical shift in the incentives that drives how games are designed
and distributed.

Not to mention how you play games and pay for them. Perhaps there would be a
small base monthly fee but also, perhaps not.

High-performing flagship titles could bill players at 3-4 cents a minute,
while less popular or less computationally demanding games could be a
significant fraction of that. And streamers that are successful enough will
see Google paying them to play.

This certainly feeds Google, but it also ties publisher revenue to the
playtime their titles get. I'm sure there are pros and cons to that, but it's
interesting. So is the potential opportunity for players to have a chance at a
piece of the action too if streaming is monetizable.

All this, by effectively _removing_ a layer of pricing abstraction. Of course,
Stadia has to work first. But even if it's not from Google I think something
like this is coming.

------
dstaley
I'm getting ready to deploy a Cloud Functions service. I wonder what I'd gain
by making it a Cloud Run service instead? I imagine cold starts for Cloud
Functions are highly optimized (since they're runtime-specific).

~~~
hn_throwaway_99
I don't fully understand how cold starts would manifest in Cloud Run, but in
any case they should be MUCH less of an issue than in Cold Functions.

Cloud Run has a default (and max) concurrency threshold of 80 requests per
container. Thus, for example, if you are running Node, you could conceivably
be handling 80 concurrent requests before needing to start another container.

Cloud Functions have _no_ concurrent requests (each instance can only handle 1
request at a time) so every concurrent request results in a cold start if
additional instances are needed to scale up.

Note, though, that this means you can't put per-request state in the global
scope in Cloud Run, but this is safe to do in Cloud Functions because you know
there that each instance is only handling one request at a time.

~~~
reaktivo
I'm not sure this is actually the case, Cloud Functions instances might be
handling one request at a time, but they call also share a global scope, as
you can see in their Tips & Tricks document[1]

[1]
[https://cloud.google.com/functions/docs/bestpractices/tips#u...](https://cloud.google.com/functions/docs/bestpractices/tips#use_global_variables_to_reuse_objects_in_future_invocations)

~~~
hn_throwaway_99
No, what I meant was that it is safe to keep request-scoped data in global
scope without needing to worry that a concurrently running request will
interfere with the state there. Normally in a Node server you cannot do this.

Cloud Functions will _reuse_ instances for subsequent invocations (that's what
"being warm" means), but separate instances do not share global scope.

------
bravura
Is there a good description of which use-cases this is good for, and what it's
not so good for?

I do NLP and ML, and want to spin up libraries as APIs.

If I have a Dockerized library that is stateless but requires a 20GB model
file, should I not use Cloud Run?

If I have an API based upon tensorflow uses a GPU, should I not use Cloud Run?

------
orasis
Boo on the round up to 100ms. I wish they would have put some pressure on
lambda by going for 50ms.

------
AtroxDev
Cloud SQL is listed as unsupported [0]. Are there any estimates when this will
change? I would love to try this out in combination with Cloud SQL.

[0]: [https://cloud.google.com/run/docs/using-gcp-
services#service...](https://cloud.google.com/run/docs/using-gcp-
services#services_not_yet_supported)

------
reilly3000
When Fargate launched it had a very high premium on pricing over EC2(like 3X!)
which has really come down, but I still wonder how Cloud Run compares. I’m on
my phone and too lazy to do the math, but my experience with other GCP
offerings has been that compute and RAM generally cost similar across services
and abstractions.

~~~
reilly3000
Okay fine, I'll run the numbers... There is indeed a substantial price premium
for this platform:

1 vCPU /hr on Cloud Run clocks in at $0.0864/hr compared to $0.0331/hr on VMs
with custom CPU or $0.0316/hr for predefined.

1 GB /hr on Cloud Run is $0.009 compared to $0.00094 for Custom RAM or
$0.00089 for predefined.

I can assume you can also forget about sustained use discounts.

I would imagine the costs of resources to deliver hot-start performance is
significant, but this makes the case for the service a lot weaker, especially
for long-running jobs that could just be tossed on a preemptible VM for
dramatically cheaper rates.

Sources: \-
[https://cloud.google.com/run/pricing](https://cloud.google.com/run/pricing)
\-
[https://cloud.google.com/compute/pricing](https://cloud.google.com/compute/pricing)

~~~
eicnix
When you compare Cloud Run vCPU pricing with preemtible VMs it becomes nearly
13x the price.

Most use cases could trade startup delay for reduced costs by running GKE with
preemtible nodes and Cloud Run on top of it. Otherwise "normal" Cloud Run and
Cloud Run on GKE could be combined into a system where on the first request an
instance on serverless Cloud Run is started and simultaneously an GKE Cloud
Run instance of the same container is ramped up to take over.

------
andr
A quick comparison to Lambda shows that $0.000028 gives you:

a) 1 second of Lambda execution at 1728MB RAM 1) 1 second of 1 vCPU + 1.7 GB
RAM of Cloud Run execution

Both services round up to 100ms per execution. The exact vCPU allocation for
Lambda is not public, so you'd need a benchmark to compare.

~~~
jsmeaton
Isn't this more like Fargate rather than Lambda?

------
mleonard
Thanks Google cloud team this looks really great. Excited to hear more on the
Next livestream. Questions: Is Cloud Run a zonal or regional resource and is
there any way to put this behind the global load balancer? Is Http2 (grpc)
support planned? Thanks.

------
nl
Is there a size limit on the containers?

That's a problem I hit on Lambda frequently.

~~~
revskill
Is lambda size related to cold start time ?

~~~
nl
No.

There is an actual limit on how big the combination of data and libraries can
be.

------
twa927
Does max. RAM usage need to be specified upfront, or what's billed is the
live-allocated amount? This is important for scenarios like running Chrome
Headless when the RAM usage varies a lot between invocations.

AFAIR AWS Fargate requires an upfront allocation?

------
alexellisuk
Has anyone measured cold start times? I know that the Istio/Envoy combination
can add 1-2 seconds on init time, plus the pulling of the container image to
whichever node/region is decided by the scheduler.

~~~
alexellisuk
Oh they have..
[https://github.com/knative/serving/issues/1297](https://github.com/knative/serving/issues/1297)

------
reaktivo
Great timing for those of us on Zeit's Now.sh v1 service which seems to be in
it's way to deprecate serverless docker deployments.

------
jessev
I see a way to set environment variables, what is the best way to define a
secret such as a database password?

------
kozikow
Any plans for GPUs?

------
bg0
Can we set up persistent storage disks with this?

------
ngrilly
How does Cloud Run compares to App Engine?

------
uzero
Any guesses when this gets canceled? I give it 1.4 years.

~~~
ubercow13
What GCP product has ever been cancelled?

~~~
rbirkby
Gcm, c2dm, datastore.

~~~
hiroshi3110
[https://cloud.google.com/datastore/](https://cloud.google.com/datastore/) is
still available.

~~~
inlined
And GCM was literally just renamed FCM. It’s been years since I worked with
the libraries but iirc GCM v3 registered tokens worked with FCM. I don’t
recall all the specifics of C2DM other than that it was recipe enough that we
built a whole push network at Parse instead.

------
borgomegak8s
Azure Functions also supports running custom containers:
[https://docs.microsoft.com/en-us/azure/azure-
functions/funct...](https://docs.microsoft.com/en-us/azure/azure-
functions/functions-create-function-linux-custom-image)

~~~
rcarmo
Except that you need to include the Functions runtime and the deployment
method is completely different. This is not an apples-to-apples comparison.

------
brunoborges
Not interested in serverless platforms that are only invocable by HTTP
requests. That's very limiting.

~~~
tgtweak
Would be great if they supported some kind of scheduling engine similar to
airflow. Could replace a lot of cron jobs.

~~~
Godel_unicode
App Engine cron is pretty sweet:

[https://cloud.google.com/appengine/docs/standard/python3/sch...](https://cloud.google.com/appengine/docs/standard/python3/scheduling-
jobs-with-cron-yaml)

~~~
tgtweak
Nice, seems like a good workaround for now and a low hanging fruit to wire
this up directly.

~~~
hn_throwaway_99
I use Google Cloud Scheduler,
[https://cloud.google.com/scheduler/](https://cloud.google.com/scheduler/) ,
to invoke Cloud Functions (actually Firebase Functions which are really Cloud
Functions under the hood).

You set up a Firebase function to run on receipt of a message to a pub/sub
topic, and then in Cloud Scheduler you schedule a post to that topic.

------
jmontano
Seems like a great alternative to AWS serverless offering.

I just want it to live past the beta, considering that last week Google killed
two of their non-beta Services.

~~~
jasonvorhe
This whole "Google is killing their services" rambling should be downvoted to
hell for each Google Cloud Platform submission.

Sigh.

