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.
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.
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.
Hey boulos, upvoted your response. Thanks for taking action on this. Agreed that GCP != Google consumer support.
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.
Message received! I just wanted to highlight that it's easy to extrapolate from individual accounts, but that can trick you. That doesn't make the current situation okay, and we get that.
You're correct--but most enterprises start out with credit card accounts when some line manager greenlights an experiment. "Time to go drop $50 million on a cloud provider this year" doesn't happen overnight, and it doesn't happen in a vacuum. Experiences like this with early-stage accounts cause significant damage to the sales process--and you'll never see it coming until after the decision has been made.
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.
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.
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.
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.
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.
Really depends our your capacity for risk. If you're a small startup team, getting the benefit of automatic scaling with extremely little management overhead (especially compared to something like Kubernetes) could be worth the lack of explicit uptime SLAs.
It is an important question, but Google services which are largely consumer-based and no cost are a very different world from Google Cloud. People get a lot of Internet Cool Guy points these days from falsely conflating the two.
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.
Uh, just last year Google increased the price of developers using the maps API by an order of magnitude with no grandfathering policy, which for many users was effectively shutting the API off completely.
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.
If nothing else, what do you expect Google to say? "No, we'll definitely be dropping this"?
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.
Google Cloud has had zero dead products in a decade existence. Just because Google phased out a couple browser extensions and a RSS feed reader doesn't mean they have a "horrendous track record" when it comes to real enterprise-tier services such as Cloud.
It's not the dead products on my case I fear but the lockdown of a Gmail account, there's already 2 gmail accounts I can't access despite knowing the password. I would not use GCP just because of that, everything might work fine and then one day you're locked out of your account and can't do anything.
Just had this with an account I setup for my parents. I have recovery email AND know when account was created - not good enough. My parents use a landline that can't get a text and apparently enough to deny them (Google won't Dona voice call). Would pay 50 to unlock. Only option is to setup a new account. Ugh. This same email used for Apple Id and they like their Apple stuff
I'm in the exact same situation, I know everything about those accounts, password & recovery email but that's not good enough. Why would I trust Google with GCP when I have personal experience that those accounts can and will be locked down without a valid reason? That does not seem a good business idea.
Does anyone have a head-to-head comparison of Google vs Amazon vs Apple cancellations? I guess the Facebook equivalent would be what of our personal information they've newly managed to monetize.
Does Cloud Run have accurate NTP time across edge servers and througu Cloud Run? I know Google runs their own version which stretches time on leap years, but I'm wondering if there's any effort to make sure that these edge servers are properly synchronized. That way things such as sub-second video stream synchronization can be done across the globe.
Thanks very much! Hope to find out more tomorrow, but just wondering if there is any equivalent to the "cold start" issue you have with Cloud Functions on Cloud Run. If not, could you point to any documentation that explains the lifecycle of how containers are loaded, scaled up and scaled down in response to requests?
Quick question out of curiosity, we have a Google Cloud org of three members at work. One member had access to Cloud Run some days ago, he stumbled upon it incidentally in the sidebar. All other members couldn't access Cloud Run. So, how come? Is early access account, not org-based?
(I'm a product manager on the serverless team at Google Cloud)
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.
Hi thanks for the reply. The only thing he could think of was that he skipped through a couple of videos on Google's official YouTube developer channel that day. But likely coincidental. (On a sidenote, when my coworker had access, autoscaling was broken, like completely, hence in part my curiosity).
Please tell your salespeople to point out to potential customers that since Fargate billing is per vCPU-hour, costs on Cloud Run are "up to 36,000 times cheaper!"
