13 ms·
Cloud Run – Newest member of our serverless compute stack
- WestCoastJustin 8y agoFYI - 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 7y agoFYI - 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 8y agoServerless 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 8y agoStreaming 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 8y agoUnary gRPC calls would cover all of my uses cases that would benefit from this product. Is that any closer on the roadmap?
- asciimike 8y agoMy 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.
- charltoons 8y agoNo gRPC support means no server-side Firebase integration, right?
- asciimike 8y agoWe don't support inbound gRPC/streaming, but we do support outbound gRPC/streaming, so things like Firestore (or other streaming gRPC products) will work fine.
- charltoons 8y agoOh, nice. Thanks for the clarification.
- mrwilliamchang 8y agoDepending on your use case, there is a way to proxy gRPC to Cloud Run in a slightly hacky way leveraging the fact that outbound gRPC works. You can run in GCE a gRPC server that whenever it gets a gRPC request, it temporarily stores the gRPC message and associates it with a session ID. It then sends a HTTP request to Cloud Run with that session ID. Then your Cloud Run instance will take that session ID to make a gRPC connection to your gRPC server in GCE. This GCE instance will then take the session ID, retrieve the gRPC request, and forward it to the Cloud Run instance. This is admittedly hacky, but depending on your use case, may be good enough.
- asciimike 8y agoHey 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 8y agoHello, 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 8y agoCloud Run engineer here. Containers are run in gVisor https://github.com/google/gvisor https://github.com/google/gvisor as the container sandbox.
- wlhee 8y agoCloud Run prevents privilege escalation by using gVisor as sandbox technology. Each container has its own isolated user-space kernel from the host. (Disclaimer: I am Cloud Run dev)
- deleted 8y ago[deleted]
- jpdb 8y agoIs knative build api supported as well?
- mikehelmick 8y agoNo, we don't currently support the Knative Build API.
- asciimike 8y agoMy understanding is that we're working on having Cloud Build support Tekton [1,2] (which is where the Knative Build API now lives) [1] https://tekton.dev/ https://tekton.dev/ [2] https://cloud.google.com/tekton/ https://cloud.google.com/tekton/
- mleonard 8y agoThanks 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.
- w-m 8y ago"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 8y agoFive 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?
- w-m 8y agoI would have been probably less irritated by something simple like "current serverless solutions". But I'm not a web developer and don't understand the differentiation details you mention, so I'm not in the target demographic here. From my outsider's perspective, serverless is something that just recently came into mainstream usage. People who this product is made for probably see this differently and thus wouldn't have a problem with the formulation. Language pedantry aside, good luck with your product launch :)
- scarmig 8y ago"First generation"? Archetypal?
- lima 8y agoThere'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).
- wasd 8y agoI'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 8y agoPosting 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
- ksec 8y agoI am wondering if Shopify were testing it. Cloudrun seems to be exactly what Shopify were doing by themselves, and they were hosting on GCP.
- helper 8y agoFrom 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 8y ago> AWS to provide a docker on lambda option isn't that AWS Fargate?
- robrtsql 8y agoYes 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 8y agoLooks 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 8y ago
- tyingq 8y agoIs 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.
- helper 8y agoWhat 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?
- asciimike 8y agoIt means that we support the same toolchain across Cloud Run (running on our fully managed infrastructure) as well as Cloud Run on GKE (running on your k8s cluster). For example: ``` # deploy to the fully managed product gcloud beta run deploy --image gcr.io/foo/bar --region us-central1 # deploy to a GKE cluster gcloud beta run deploy --image gcr.io/foo/bar --cluster myCluster --cluster_location us-central1-a ``` Cloud Run on GKE specifically adds the Knative CRDs (e.g. Knative Serving) to your GKE cluster, giving you additional autoscaling and different rollout primitives.
- ryangregg 8y agoProduct 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.
- sbr464 8y agoCurious if websockets, sticky sessions are supported?
- asciimike 8y agoNot 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.
- sbr464 8y agoIs there support or integration for the new GCP web application firewall/security product?
- milancurcic 8y agoWe at Cloudrun [0] are excited to try Cloud Run for scaling our platform! :) [0] https://cloudrun.co/ https://cloudrun.co/
- steren 8y agoWhile listening to Cloud Run on Spotify https://open.spotify.com/artist/4gCabDwZ2AdhrBYYWQT9t2?si=tLvYL0EmRW28ylJ-D2ZU7g https://open.spotify.com/artist/4gCabDwZ2AdhrBYYWQT9t2?si=tL...
- djhworld 8y agohttps://cloud.google.com/run/docs/reference/container-contract https://cloud.google.com/run/docs/reference/container-contra... 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 8y agoOh! It's great documentation, sucint, clear, to the point...
- euph0ria 8y agoTo 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 8y agoHave 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 8y agoThanks, 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.
- jpatokal 8y agoIf you purchase Google production support, with credits or otherwise, it's available 24/7 and not tied to a single "contact person". In addition, billing support (which includes things like being suspended for fraud or abuse) is free, available to all and also 24/7. All these channels are responded to by real live humans who can see what "the algorithm" did and why, and overrule it if need. Disclaimer: I work at GCP and used to work in support.
- mychael 8y agoFinally a serverless technology that is actually serverless to the developer ($0 when idle).
- tomjohnneill 8y agoFor 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 8y agoCurrently just `us-central1` since that's the only region Cloud Run is supported in.
- sbr464 8y agoCan 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 8y agoWe'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.
- etaioinshrdlu 8y agoIt 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.
- infinitone 8y agoNot just cores. But memory currently is capped at 2GB.
- steren 8y agoFor 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 8y agoBut 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 8y agoPooling 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).
- sivakon 8y agoI 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 8y agoCloud 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-deploy https://cloud.google.com/run/docs/quickstarts/build-and-depl...
- davidbanham 8y agoAny ETA on being able to access Cloud SQL from Cloud Run containers?