
Cloud Run – Newest member of our serverless compute stack - wilsynet
https://cloud.google.com/blog/products/serverless/announcing-cloud-run-the-newest-member-of-our-serverless-compute-stack
======
euph0ria
To Google people, do you have any suggestions for startups how to start using
your services for production workloads and: 1) Not having to take the $250
monthly fee per dev that needs to be able to contact you. Just increases the
start cost massively for your services.

2) Not having to worry about being hell-banned and not being able to restore
your account with Google, such as "guilty-by-association" for devs in
PlayStore/gApps etc trickling over to closing down the whole account. We have
read so many of those stories here on HN lately that I'm terrified to use
Google for anything business related as we run the risk of losing everything.

The Cloud Run product looks great and would love to use it but the above two
issues makes it a no go for us.

~~~
asciimike
Have you reached out to:
[https://cloud.google.com/developers/startups/](https://cloud.google.com/developers/startups/)

They should be able to give you a pretty large chunk of credit (I assume it'll
cover support as well). It should also give you folks to contact and help
prevent the latter issue.

~~~
euph0ria
Thanks, however, it seems limited to 12 months only, which is usually the
initial prototyping phase of a product prior to launching. Also, feels strange
to have to be in some type of program and beg for mercy with a contact person
in order to alleviate the extremely strange behavior of permanent cancellation
by algorithms. What if the contact person we have gotten to know have moved on
to a different business etc? Feels unreliable.

~~~
teraflop
I can understand the concern about getting your account banned, but: if after
12 months, your startup can't afford $250/month for support, you probably have
bigger problems.

To put it another way: do you think the level of support that Google would be
able to provide is less valuable than a few percent of an engineer's salary?

~~~
euph0ria
Google support seems to charge per person, so suppose you are a few persons,
ie at least 3 sharing the support then it's $750/month. Also, you are assuming
US salaries, when looking at many other countries $250 is upwards 10% of the
salary. Google support is valuable, but, going with AWS for example is a lot
cheaper. Now, if you are a VC-backed or otherwise funded company, then this is
a non-issue, but there are hundreds of thousands of businesses that have a
total spend on infra that would be less than the support fee from Google.

------
wasd
I'm so excited about the App Engine updates. I'll be signing up for the Ruby
2.5 run time to replace Heroku in our stack.

> Today, we are announcing support for new second generation runtimes: Node.js
> 10, Go 1.11, and PHP 7.2 in general availability and Ruby 2.5 and Java 11 in
> alpha. These runtimes provide an idiomatic developer experience, faster
> deployments, remove previous API restrictions and come with support for
> native modules. The above-mentioned Serverless VPC access also lets you
> connect to your existing GCP resources from your App Engine apps in a more
> secure manner without exposing them to the internet.

~~~
asciimike
Posting here as well in case folks aren't reading the other thread:
[https://cloud.withgoogle.com/next/sf/sessions?session=SVR209](https://cloud.withgoogle.com/next/sf/sessions?session=SVR209)

------
asciimike
Hey folks, one of the Cloud Run PMs (along with @steren, @ryangregg,
@lindydonna, @stewart27, and others).

We're super excited to announce Cloud Run and Cloud Run on GKE, both
implementing the Knative Serving API. Please let us know if you've got any
questions!

~~~
rcconf
Hello, I had a question about how Cloud Run handles security between
containers being run on the cloud.

I assume my container runs alongside other containers on the same host, how do
you prevent privilege escalation exploits?

~~~
mikehelmick
Cloud Run engineer here.

Containers are run in gVisor
[https://github.com/google/gvisor](https://github.com/google/gvisor) as the
container sandbox.

------
helper
From a developer perspective, deploying a docker container with a plain http
server is much more appealing than the hoops you have to jump through to use
the lambda custom runtime stuff. I hope this gets AWS to provide a docker on
lambda option.

~~~
aksx
> AWS to provide a docker on lambda option

isn't that AWS Fargate?

~~~
robrtsql
Yes and no--Fargate is a Docker container which runs on an ECS cluster that
you don't have to manage, sure, but it doesn't scale down to zero. As far as I
know, there's no support for running an HTTP endpoint and then having the
container start in response to a request coming in. You could build that
yourself (although I suspect it would require running some long-lived
infrastructure, defeating the purpose of scaling the Fargate service down to
zero) but I think the cold start times for a Fargate container would be
prohibitive--maybe it gets better once you've already scaled up, but in my
exploration I've seen Fargate take 45-70 seconds to run a new container. I
suspect this is due to Fargate running in your VPC and therefore probably
requiring a network interface to be created before the container can be ready.

The exciting part of Cloud Run for me is not that I don't have to manage a
Kubernetes cluster, but that I don't have to pay for it when my service is
sitting idle.

~~~
jmathai
Looks like AWS Faragate pricing is per invocation and duration of tasks.

> Pricing is per second with a 1-minute minimum. Duration is calculated from
> the time you start to download your container image (docker pull) until the
> Task terminates, rounded up to the nearest second.

[https://aws.amazon.com/fargate/pricing/](https://aws.amazon.com/fargate/pricing/)

~~~
robrtsql
A "task" in ECS means a container. In Fargate, in order to be ready to receive
requests 24/7, you have to pay to have a container running 24/7\. In that
sense, it feels a lot closer to EC2 than it does to Lambda.

------
djhworld
[https://cloud.google.com/run/docs/reference/container-
contra...](https://cloud.google.com/run/docs/reference/container-contract)

Details the contract your container must meet to run on the service and
limitations you might run into

Quite a nice document to be fair.

Would be interested in hearing what use cases people would use this for, over
say Cloud Functions or AWS Lambda. I'd imagine the flexibility of being able
to run anything that supports HTTP is quite attractive.

One thing I did spot though is the container instance is limited to one vCPU,
I wonder if people will hit performance ceilings? For lambda they abstract the
CPU allocated based on the memory tiers, I'm not sure if this is the same
though

~~~
tecleandor
Oh! It's great documentation, sucint, clear, to the point...

------
WestCoastJustin
FYI - thread from yesterday around the docs and concept:
[https://news.ycombinator.com/item?id=19610830](https://news.ycombinator.com/item?id=19610830)

This appears to be the accompanying blog post. So, not a dupe and explains the
higher level goal here. The post from yesterday, was before the product was
actually publicly released, if that gives more context as to why this is new
news.

~~~
WestCoastJustin
FYI - I just posted a review video where I walk through Cloud Run doing some
demos. Check it out at: [https://sysadmincasts.com/episodes/69-cloud-run-with-
knative](https://sysadmincasts.com/episodes/69-cloud-run-with-knative)

------
lima
Serverless with gRPC would be awesome. There's grpc-gateway, but native
support would be even better.

Surely it won't take long - the product itself has a gRPC API:
[https://cloud.google.com/run/docs/reference/rpc/](https://cloud.google.com/run/docs/reference/rpc/)

~~~
asciimike
Streaming HTTP and gRPC support is on our roadmap, but it's still a ways out
:(

On the comment about how the control plane APIs support gRPC: the serving
infrastructure for the data plane is pretty different from the control plane,
so it's unfortunately not a direct map to supporting gRPC on the data plane.

Another possible solution is to run an API gateway that does gRPC to JSON
conversion and have that invoke your service.

~~~
lima
Unary gRPC calls would cover all of my uses cases that would benefit from this
product. Is that any closer on the roadmap?

~~~
asciimike
My understanding is that the major issue we have is with streaming (sticky
sessions to backends that are autoscaling is tricky), so I assume that unary
would be easier. I admit that I haven't dived too deeply in to this though.

EDIT: looks like we could do unary gRPC if gRPC wasn't only supported on
HTTP/2\. So the current implementation basically requires we solve sticky
sessions/streaming.

------
helper
What does "Cloud Run on Google Kubernetes Engine" mean? Is there anything
beyond the idea that a plain docker container can run on Cloud Run or on GKE?

~~~
ryangregg
Product manager for Cloud Run on GKE here.

Cloud Run on GKE brings a managed experience for Knative/serving and Istio
that aligns with Cloud Run. We install and manage the Knative version in your
cluster and keep it running for you. Above what you get with base Kubernetes
ability to deploy a container, Cloud Run on GKE gives you request-based auto-
scaling of container instances, network programming with Istio, and
Stackdriver integration for logging, monitoring, and metrics. You also get the
Cloud Run UI and CLI to deploy, manage, and update your services.

One of our core goals with Cloud Run is to enable serverless portability; not
just for workloads, but tooling and developer experiences. By offering Cloud
Run in both a hosted and Kubernetes platform, both enabled by Knative, you can
leverage compatible serverless tooling and knowledge across the range of
platforms from hosted to GKE to k8s anywhere.

~~~
wisswazz
Does this mean that by using Cloud Run GKE I can also leverage the primitives
provided by Istio and Knative Serving?

~~~
asciimike
Cloud Run on GKE is Knative (which relies on Istio) installed on your GKE
cluster, and updated by us. So yes, you can go and muck around with lower
level Istio/K8s primitives, but only to a point (there are places where you
can break Cloud Run on GKE if you configure things particular ways). Over time
we're working on making those actions more clear and ensuring that you get all
the benefits of the Istio mesh built in, plus the ability to reconfigure to
suit your needs (e.g. adding Istio RBAC like we have with Cloud IAM on Cloud
Run).

~~~
wisswazz
Gotcha! So, things like adding Knative eventing which uses serving should be
fine while using Cloud Run?

------
mleonard
Thanks Google cloud team this looks really great. Quick question: Is Cloud Run
a zonal or regional resource and is there any way to put this behind the
global load balancer? Thanks.

~~~
asciimike
It's regional (and currently only in `us-central1`, though more regions are on
the way). We're working on GCLB integration.

~~~
mleonard
Great good to know. Thanks.

------
milancurcic
We at Cloudrun [0] are excited to try Cloud Run for scaling our platform! :)

[0] [https://cloudrun.co/](https://cloudrun.co/)

~~~
steren
While listening to Cloud Run on Spotify
[https://open.spotify.com/artist/4gCabDwZ2AdhrBYYWQT9t2?si=tL...](https://open.spotify.com/artist/4gCabDwZ2AdhrBYYWQT9t2?si=tLvYL0EmRW28ylJ-D2ZU7g)

------
tyingq
Is there info on cold start times for various languages, or configurations?
Lambdas, for example, are pretty slow starting if they need connectivity into
a VPC, or use Java.

~~~
sbr464
I’m also curious about cold start performance, latency.

~~~
asciimike
Wanted to drop in and say that I've seen this and am looking for any data that
we're willing/able to share on our internal benchmarks.

------
tomjohnneill
For hosting a Firebase app, with the hosting rewrites (like:
[https://firebase.google.com/docs/hosting/cloud-
run](https://firebase.google.com/docs/hosting/cloud-run)), what regions is
this available in?

Is it just us-central?

~~~
asciimike
Currently just `us-central1` since that's the only region Cloud Run is
supported in.

------
sbr464
Can Cloud Run work with GCP Memorystore (managed cache)? Also, one limitation
of GCP cloud functions was the ability to communicate directly to a private
network VM, although a solution is in beta I think. Does Cloud Run have this
limitation?

~~~
asciimike
We'll be adding VPC Connectors to Cloud Run shortly, which will let it talk to
Memorystore. As you mentioned, they went Beta for GCF and GAE today.

------
sivakon
I have so many batch jobs that run on GCE. Can I run some of them on Cloud
Run? I can only run HTTP services now. My use case is very similar to AWS
batch.

Currently, I use GCE with create-with-container and Cloud scheduler to manage
batch loads.

~~~
steren
Cloud Scheduler can trigger a Cloud Run service. And this Cloud Run service
can run anything, including bash scripts. Take a look at the "Shell" tab in
[https://cloud.google.com/run/docs/quickstarts/build-and-
depl...](https://cloud.google.com/run/docs/quickstarts/build-and-deploy)

------
etaioinshrdlu
It would be really really amazing if it allowed a large number of CPU cores.
Like 64 cores. That would make it interesting for ML inference workloads.

~~~
steren
For 64 cores, I recommend leveraging custom machine types with Cloud Run on
GKE. We are working on more CPU sizes for Cloud Run, but not in a near future
for more than 2 vCPUs.

~~~
etaioinshrdlu
But users want the per-second billing and fast cold start times too.

I understand this is kind of a hard CS problem and is basically rooted in
needing to move a lot of data around very quickly, all while making the
software low latency as well.

But solving these is kind of the point of a FaaS.

Otherwise we could just run containers on VMs and autoscale ourselves. With
terrible cost and cold start times.

Maybe look at how Jelastic does it for a unique take on this.
[https://jelastic.com/public-cloud-pricing/](https://jelastic.com/public-
cloud-pricing/)

This is probably the model that would make users the happiest.

Having poked a bit at how Jelastic does it, it seems they drop a pool of users
on a 32-core machine and load balance the users containers with live migration
to less utilized machines.

Imagine GCP doing something similar. Drop a big pool of users onto 96 vCPU
instances. If an instance starts to get overutilized, live migrate some user
containers to a new instance.

Same type of thinking that is probably behind AWS Lambda: how do you satisfy
bursty workloads for a lot of users cost effectively? Pool the users. Assume
they won't all burst at once.

That has got to be one of the biggest benefits to large public cloud
computing.

~~~
jacques_chester
Pooling already happens, AFAIK. On AWS at least you have to pay extra to not
be pooled with other customers (ie. for exclusive use of a physical machine,
regardless of your VM type).

------
sbr464
Is there support or integration for the new GCP web application
firewall/security product?

~~~
asciimike
I might have missed a product announcement today, but is this Cloud Armor
([https://cloud.google.com/armor/](https://cloud.google.com/armor/))?

If so, no, though we're working on supporting Cloud Armor, CDN, Load
Balancing, etc.

~~~
sbr464
Yes, thanks, Cloud Armor is what I meant.

------
mychael
Finally a serverless technology that is actually serverless to the developer
($0 when idle).

------
davidbanham
Any ETA on being able to access Cloud SQL from Cloud Run containers?

------
sbr464
Curious if websockets, sticky sessions are supported?

~~~
asciimike
Not on Cloud Run, though you can do this on Cloud Run on GKE.

There are some interesting billing implications of persistent connections
(e.g. we don't know what's going on in that session [if there's traffic or
not]), so we'll likely have to bill you the entire time the connection is
open.

------
w-m
"Traditional serverless offerings come with challenges such as constrained
runtime support and vendor lock-in. [...]"

I'm quite aware that there's a technology hype cycle in web development,
quickly replacing last year's fad. But whoever came up with the idea of
putting the words `traditional` ("following or belonging to the customs or
ways of behaving that have continued in a group of people or society for a
long time without changing") and `serverless` together is taking this to a new
level of ridiculousness.

~~~
asciimike
Five years is a long time in a world where front end frameworks seem to change
every six months ;)

Kidding aside, how would you suggest we re-phrase this to make it clear that
we think that arbitrary Docker containers + conformance to the Knative spec
(which you can run anywhere) is a clear differentiator?

~~~
lima
There's a whole section on "Enabling portability with Knative" and even though
I only skimmed the page, I got the message that this is an open standard just
like Kubernetes.

As for running regular Docker/OCI containers, I would put more emphasis on how
awesome this is for developers:

It's just regular HTTP in Docker containers. You can debug and develop this
locally without mocking anything, and it's the same code that runs in
production!

And it's all open source. No need to install a Lambda emulator that is almost,
but not quite, like the real thing.

I never even considered using AWS Lambda due to the lock in and how annoying
it is to work with, but this is something I'll evaluate (by trying it on my
local k8s cluster).

