Cloud Run beta pricing
cloud.google.com
cloud.google.com
"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.
Not arguing against the choice, but at some level, you are paying for the provisioning costs of the cloud provider. The higher initial costs of provisioning is what you may be escaping, and instead paying on an ongoing basis (as if you’re leasing equipment and services).
Once your needs scale significantly, cloud providers would end up being quite expensive if your load is not highly variable.
Disclaimer: I work on GCP but have only touched Cloud Run/Knative a little bit.
Most real-world loads are in fact pretty variable.
But also Closer to Fargate from a programming paradigm perspective, as the deployment unit is “container image”.
>Pretty much what I have wanted since I first started learning about Docker.
Why? I have a use for lambdas in an application I’m working on. But I don’t really get why you want stateless containers that spool up and down on demand. Is it for things like “I need this entire existing program to run and can’t refactor it to a lambda itself”? I only need to do some API processing and data we work, so I’m not entirely sure what starless containers are for. Might be a dumb question!
Vs. Go Lambda: https://docs.aws.amazon.com/lambda/latest/dg/go-programming-...
The Cloud Run steps aren't that complex and you get something you can easily run on your local computer too.
also cron jobs do not work since the computations only work as long as the container is running.
it also still does not support .net since gvisior does not support it :(
https://cloud.google.com/run/docs/reference/container-contra... https://cloud.google.com/run/docs/issues
it's basically AppEngine v3 (without long running stuff)
The services that Google dropped were either big bets that ended up as massive failures in the marketplace (e.g. wave, google+) or services that were neither big nor strategic to google (e.g. google reader, google code).
GCP is neither.
If you're not convinced by the fact that Google has been pouring billions into Google Cloud for over 10 years now, organizes multi-day conferences promoting it, launches new features monthly, then no rational argument will convince you that they won't drop GCP because they also dropped google reader.
Sure. But this one little service inside GCP? Tiny.
I'm not the to make commitments but our history has been solid, and our deprecation policy is embedded in our terms of service for every Cloud user.
The only product I can remember us deprecating in GCP was Prediction API in favor of the much-preferred Cloud Machine Learning Engine, and with that came communication to every single affected admin and a _year_ before cut-off.
Unless one is twitter sized limiting ones exposure to googles arbitrary decisions is quite reasonable.
I can get a person to talk to at microsoft for my tiny account easy and I know neither they nor Amazon will just shut me down overnight.
It's not just the consumer side; Google doesn't exactly have a spotless reputation for developers, and assuming the post must be somebody faking being concerned for "Internet Cool Guy points" is just tone deaf.
Didn't they just 10x the price of Maps api calls recently?
Amazon has a bad track record when it comes to hardware products but hasn't had much volatility when it comes to services they offer.
It's reasonable for a company not to guarantee support timeframes during a beta program.
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.
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.
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.
We usually extend the deprecation timeline if a product is important or is hard to migrate.
Master/Slave datastore deprecation takes 3 years since the announcement of deprecation.
Python2.5, 4 years since deprecation announcement to fully deprecated.
Java 6 was officially deprecated in July 2017 but if you still have an app deployed in Java 6, chances are they can still serve traffic just fine. Same applies to Java 7 (this is partially due to JVM backward compatibility but there are non-trivial engineer works involved)
I hope this gives you some confidence in Google's cloud offering.
For all deprecated features of App Engine, you can see https://cloud.google.com/appengine/docs/deprecations/ (note alpha/beta features are deprecated in less than 1 year which is WAI)
I've used GCP in the past, including decisions on which cloud providers to use where we spent north of 1M USD/month.
Honestly Google's efforts are best focused on support issues like this and customer service rather than features to compete with AWS at the moment. A lot about GCP's setup is simpler and their network/hardware is well known to be better per dollar spent.
However, I've always found the ability to contact an AWS rep and work through a tough situation on billing/quotas to be much more convenient.
That often shifts the decision in Amazon's favor.
To be clear, this person seems to have reached Support (I'll know more if they reach out to me) but is probably mid-way through the "Are you sure you didn't do this?" or something particular to debit cards.
Enterprises don't have the same experience, because you don't use a credit/debit card to pay for $1M/month in anything :). As an Enterprise, you also have dedicated folks in sales and professional services working with you, and so on.
I don't disagree that Support and customer empathy are huge factors of what goes into picking a provider. We need to improve, likely more than other providers. We all hate knowing that if you happen to know someone at Google, you get better help.
But, tl;dr: GCP Support != Google consumer "support" and individuals on credit/debit cards != Enterprises.
I didn't mean for my response to be perceived as negative for GCP, was only hoping to inspire those at GCP to continue to focus on the customer experience rather than features. AWS certainly needs the competition and I've also had great experiences using Google's cloud platform.
The early access was based on a user account being added to an access list. But, I'm not sure why your team member had access without explicitly asking for it.
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.
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.
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/) integration, which will let you create multi-regional or global service.
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.
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!
What about cold starts, debugging and runaway expenses?
I do agree as far as cold starts and runaway expenses go, although those issues seem inherent with FaaS.
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.
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 :)
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.
In order to be able to do that, and to save costly resources (memory and CPU) you need the workload to be interruptible vs flexible environnent which is persistant. In a sense this is closer to lambda but supporting native containers if I read into it correctly.
That's 80 concurrent requests per container.
[1]: https://azure.microsoft.com/en-ca/services/container-instanc...
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.
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.
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.
[1] https://cloud.google.com/functions/docs/bestpractices/tips#u...
Cloud Functions will reuse instances for subsequent invocations (that's what "being warm" means), but separate instances do not share global scope.
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?
[0]: https://cloud.google.com/run/docs/using-gcp-services#service...
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/compute/pricing
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.
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.
That's a problem I hit on Lambda frequently.
There is an actual limit on how big the combination of data and libraries can be.
AFAIR AWS Fargate requires an upfront allocation?
https://cloud.google.com/appengine/docs/standard/python3/sch...
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.
The business value though is in data-based events. Data is inserted/updated/deleted in databases (SQL and NoSQL), event streaming, queues, identity management systems, and so on.
Until there is a way for Cloud Run to easily plug its 'functions' to those sort of events, the solution is not ready for real world use cases -- unless of course one is interested in building a whole distributed system architecture around webhooks.
That flexibility would be great. Hope this is on the radar! Cloud run triggers. Being able to pass the event metadata in would be great too.
Other RPC mechanisms have no trouble with that.
Bidirectional streaming is irrelevant here, the question is what's so limiting about using HTTP for this use-case? (i.e. by far the most popular protocol used for invoking remote service requests).
Can you post an example/blog post of this approach?
- https://developer.github.com/webhooks/
There's also a Community WebHook plugin for ServiceStack:
I just want it to live past the beta, considering that last week Google killed two of their non-beta Services.
Sigh.