My two cents, GCP has a few excellent gems which are better than pretty much any competing cloud offering:
- Cloud Run. Best way to deploy containers hands down. All of the benefits of a serverless/containerized workload with all the ease of a traditional VPS deployment. Extremely cheap (pay $0 for side projects with little traffic).
- BigQuery. Very easy to use with immense power without having to deal with the details yourself. Billing can be either extremely cheap or rather expensive depending on what you're doing, though.
- GCS Archive Storage. 1/3 the cost of glacier for storage ($0.0012/GB/Month lol), but more for retrieval. Has none of the annoyances of Glacier (you can download your files instantly, upload using normal APIs). Perfect for extremely cheap backups.
- Cloud Spanner. I've not had a reason to use this yet myself, but there really aren't any comparable offerings that I know of.
Yes Google Cloud Run is my go-to for all my side projects, and AWS doesn't have anything equivalent. Never saw any reason to use AWS for that reason as Google has everything else I'd need. And if I just want a cheap VPS, would prefer to use something cheaper like Linode or Digital Ocean.
GCP and AWS are cheap for small and low traffics applications. But once your usage passes a certain point, you'll quickly find out they're more expensive than other vendors. The problem is, once you reached that point, you're probably already locked yourself in by using their specific offerings not found anywhere else. Limiting yourself to plain vps/containers/k8s might help preventing lock in.
And yet many large enterprises with existing data centers have made forays into cloud only to discover how stunningly expensive it is once the free credits run out.
As always it depends what you need. If you think you might need a database that's not MySQL and maybe a bucket to host your images and static assets then nearlyfreespeech is already not a good match any more if you prefer to have everything in one place.
For small projects or Wordpress installations you can of course find a lot of very cheap or even free options as it's such a commodity by now.
I've paid $0.00 for my many AWS Lambda functions, and will always pay $0 so long as I keep it under 1 million executions per month (and AWS keeps this free tier going). I also use SimpleDB, SES, and other services that also cost $0.00/mo. The only thing I pay for is S3, which totals about $0.30 per month, for a few gigs of data. And I'm very happy with AWS, It's been costing me less than $6 per year to build out and run a complex web app, albeit with no users. But still, AWS absolutely does scale down to zero very nicely.
App Runner is an abstraction on top of FarGate designed to compete with Cloud Run, which is why it doesn’t scale down to zero. I too haven’t found anything that beats the simplicity of a GCP deployment sigh..
In fact, I was waiting for years for them to add a min instances option. But otherwise, agree, been running large and small production workloads since it launched and its been great.
It really depends on which workloads. We have teams working only on FinOps to optimize our architecture to take advantage of various cloud pricing models.
Enterprise spend on cloud is a massive topic right now and definitely in the spotlight. A consensus is developing that the current implementation of public cloud promotes lock-in and overall much more expensive at scale.
Cloud is complex and engineers are expensive. Instead of throwing CPU cycles and disk at the problem (which is cheap compared to engineer time), we are nickel-and-dimeing everything, and changing our architectures to hack the cloud pricing models. It's pretty silly.
We used cloud run for a while and it's great. It does not allow for background threads though and that caused us to upgrade the setup eventually.
Upgrading from cloud run to use proper vms was very easy because vms can be booted with a docker container as one of the arguments. It will just go off and run that with a default OS. Running docker containers in gcloud is super easy.
And scaling that is easy too. Basically you define an instance template that defines vm details; including the docker container url. And then you update your instance group with that template and all the instances are replaced one by one. You use the instance group as a service for your load balancer and with the right health checks configured this basically gives you zero down time deployments, auto scaling, etc. If there's an issue starting the container, it just aborts the restart and continues running the old containers.
The closest thing in AWS would be ECS but it's a lot more hassle to setup.
One great feature in gcloud is "copy this screen/dialog/whatever as a gcloud command". That made scripting the above super easy. We use github actions for all this. For each service, we use 1 command to update the template and 1 command to deploy it.
Cloud Postgres had some issues last year though -- when some UK datacenters stopped because of HVAC failure then HA PSQL instances got stuck during failover and there was no manual way of resolving this .
"Customers experienced downtime on Tuesday, 19 July 2022 starting at 09:25 US/Pacific. 36% of zonal (non-HA) instances in europe-west2-a were affected. Additionally, 31% of regional (HA) instances whose primaries were located in europe-west2-a experienced extended downtime because they were unable to successfully fail over to another zone. Finally, customers experienced some failures during the incident for backup, instance creation, update, delete, restart, export, and Database Migration Service operations. The total impact duration was 17 hours, 30 minutes."
Has Cloud Functions solved their logging issues yet?
Last I checked, the lifetime of the function was bound to the lifetime of the request. So you have to fully flush your logs to their log ingress service before you respond to a request, otherwise GCP will suspend the function and eat your logs.
Originally, this resulted in me having - to my surprise - very few logs coming from my functions.
Once I discovered what was going on, it resulted in me having to increase the latency of responding to the request while I waited for logging to flush to GCP's log ingress service.
Are you using a log service directly, or stdout? Stdout has no such issue. On Run (and therefore functions 2nd gen) you get a SIGINT before the container is shut down. Open Telemetry is pretty easy to configure to flush on SIGINT in the background.
My guess would be that their app isn’t running with PID 1. This can happen when services are launched from an entrypoint script in docker without using exec. If the request is fulfilled and the system sends a sigint to the container, docker will relay that to whatever is running on pid 1. If that’s their app, it’ll flush logs and quit. If their app is using another pid, docker will kill the container by force.
I built a service with a few functions (golang based) that ran just fine for over a year with no log flushing issues.
I did actually have an issue where it was logging two blank lines, which was annoying. It definitely wasn't coming from my code and it got fixed at one point, then reappeared later on. I gave up trying to resolve it.
That said, their logging system is fantastic. I found it really easy to deal with.
Although it works and is solid, I wouldn’t say it’s fantastic. My impression is that Google makes limited investment in it to steer customers towards their own services such as Cloud Spanner.
- Major versions are 6 months late
- Small instances are horribly slow
- Integration with other services is poor (e.g. the Cloud Run integration doesn’t work with a database private IP, so you have to fallback to configuring a VPC and connecting the standard way)
- IAM authentication, although great when it works, is complicated and poorly documented
- The UI has very few features, for example it isn’t possible to query the database from it
- Although I’ve never seen any provider have it, automatic upgrades between major versions would have been nice.
¯\_(ツ)_/¯ I started with a small instance, moved up to the next size so I could get more connections and it ran flawlessly for over a year with 50-60 RPS from Cloud Functions, hitting it 24/7. Total price was under $40 a month. Zero regrets and would do it again in a heartbeat.
Have you considered Backblaze B2? (It has free egress!)
I think GCS is pretty good as a coherent offering that includes the various storage tiers + auto-classing + lifecycle notifications to pub/sub to feed Cloud Dataflow, etc. But if you're storing data purely for retention or disaster recovery, you should consider a service architected as a backup provider that happens to present an object-store abstraction, rather than an object-storage provider that happens to support your backup software — often you'll find very different that the provider themselves have made very different CapEx trade-offs, resulting in very different pricing models, that can favor your use-case heavily.
(I say this as someone who uses GCP for elastic load, but has non-IaaS bare-metal for base load; and where the DB instances living on that bare metal do their pgbackrest backups + WAL streaming against a B2 bucket.)
But, of course, if your data-to-be-archived is originating in GCP, it may well cost you more to send it over an external provider like Backblaze, than it costs to just keep it in GCS. That is, as they say, "where they get ya."
> B2 currently costs 6 $/TB/month, GCS Archive Storage costs 5x less at 1.2 $/TB/month.
Sure, but does the GCS "archive" storage-class really fit your needs? Anything less than GCS's "nearline" storage class, has fetch costs that swamp the storage costs themselves.
If you're doing FinOps/SecOps (storing customer invoice PDFs for compliance, audit logs in case of a retroactively-discovered hack, etc) — where the likelihood of fetching any given piece of archival data approaches zero — the "archive" storage class makes a lot of sense.
But if you're doing DevOps — e.g. storing infra backups intended to be used for PITR in case someone fat-fingers a SQL DELETE, or in case a bad upgrade corrupts a machine's state, or even just to serve as a read-replica bootstrap base-image (think e.g. pgbackrest) — then the "archive" storage class is ill-suited, because you actually are quite likely to read back the data. (And in fact, if you regularly test your backup restore process, you're essentially 100% likely to read back the data!)
For this reason, I've personally never seen anyone use "coldline" or "archive" storage classes for DevOps infra backups. Instead, SREs seem to gravitate to the "nearline" storage class for this use-case.
(There's also the fact that anything beyond "nearline" requires keeping the data around for quite a long time, paying for all that time the data sits around. The processes involved in DevOps infra backups often trigger periodic full backups, that then obviate the need for retaining previous full/incremental backups. Do you really need a 12-month-old DB backup, or do you only need the 1-month-old and 2-month-old ones?)
And Backblaze B2 is cheaper than GCS "nearline" storage — without any of the minimum storage lifetime requirements of GCS's colder storage classes.
(GCS Nearline vs Backblaze B2 is not as much of a slam-dunk as when comparing them to GCS Standard — $10/TB-mo vs $6/TB-mo; but if your base-load is outside of GCP, adding back in the GCS egress costs to the equation still makes it seem pretty obvious that GCS won't come out the winner on a TCO basis.)
> Do both of these guarantee that if a single data center location catches fire, your backups will not be lost?
Hard to say, actually! Let's look specifically at the case of a fire.
GCP uses the IaaS-standard term "availability zones" to describe data centers in the same region that, along with other types of isolation, are physically-distant enough that they can't catch each-other on fire. From GCS docs:
> Cloud Storage redundantly stores objects that are written to it in at least two different availability zones before considering the write to be successful.
Backblaze, meanwhile, seems to use the term "vaults" here, and seem to use it to mean racks/rooms of backup storage that are seemingly independent from a power/cooling/data perspective. (And possibly with their own isolated little room that has its own fire suppression? They don't mention it, but that's how I'd picture it.) They say that there are multiple vaults "per data centre." But often an entire campus of physically-isolated buildings — what in IaaS terminology would be separate AZs — would be considered one "data centre" in traditional hosting terms, if it's all owned by one company and operated by one shared ops staff. Since Backblaze don't introduce anything quite like the AZ concept in their docs, it's unclear whether their data centres are able to guarantee data durability in the event of a fire that destroys a single "vault."
What is clear, is that neither Google nor Backblaze considers this type of data durability to be the most important kind. Which makes sense: there are other types of disasters that can befall a data centre, or even an entire city, that will knock out (and potentially corrupt!) all AZs in that "region." I'd mention floods as the obvious thing to picture, but nobody builds a data centre on a floodplain. Instead, how about: climate change shifting the paths of tornadoes unpredictably; compression of a tectonic plate resulting in random areas of land (potentially inside a city) having the earth heaved and thrusted up by as much as meters; and key cities — and data-centers themselves as strategic targets, actually! — being bombed during a war.
Designing your archival storage to be resilient to these problems, will of course also protect your data in the event of a smaller-scale disaster like a fire, meteorite impact, or some spiteful person ramming a truck into one of the DC's buildings.
Therefore, Google and Backblaze have both designed in inter-regional replication for the purposes of "geographic data redundancy." GCS has "dual-region" and "multi-region" buckets; and Backblaze has "Cloud Replication" (https://www.backblaze.com/cloud-storage/features/replication) where you essentially make Bucket A in region A into a streaming read-replica of Bucket B in region B.
In both of these cases, enabling the feature costs money. Both providers consider the use-case for this level of durability so rare that they don't make it a guaranteed default with attempted cross-customer subsidization; but instead just offer it to the few customers who think they really need it, or who are required by law or regulation to do it.
Cloud Run is the only reason to use GCP for me. I haven't seen any product/service that simple to use. It even offers mapping domain names. All my projects run on Cloud Run.
We use GCP at my current company and I've used AWS a lot in the past.
Managing IAM users and roles on GCP is much more pleasant than AWS, and if you happen to use Google Workspace for you org, it approaches (as an infra engineer) the sublime.
GCP projects are a really intuitive way to isolate resources that you don't want to be able to talk to each other by default.
GKE has been very reliable.
BigQuery got expensive faster than I was expecting, but it works and integrates well with GCP IAM and makes managing access to datasets easy.
On the less positive side, support is lackluster, and GA doesn't necessarily mean what you want it to mean.
Edit: Almost forgot! Again, if you use Google Workspace, then IAP is fantastic.
I miss the glory days a few years ago when getting someone on the phone across your org as $400. From what I've read the Oracle boys flooded in and "sorted" that "problem"...
I share the same experience and opinion. I cannot imagine what a significant argument would be to use AWS instead of GCP that outweighs the benefits and the seemingly integrated services. GCP has so far covered 99% of my use cases, and I can testify that I have a lot of advanced cases linked to data management, information security, networking and more. I am open and do not judge AWS, and perhaps its also a matter of what you are used to. However my style and approach to problems is more in alignment with GCP. I am for example of the opinion that the cloud provider should take care of everything linked to infrastructure, maintenance and as well scaling. And all of that should be as simple as possible. There is no need to overcomplicate. In this way I can focus on what makes my product unique, rather than spending my time on over-engineering repetitive features with zero value added.
For a fairly simple setup AWS automates a lot of things. If I just want an EC2 instance and a database, the VPC already exists and there is now even a button on an RDS that says something like "connect to ec2" which sets up the security groups on both for you.
However the argument against using GCP has already been stated in this thread multiple times.
- Will it exist in 3-5 years. Google has a reputation for a reason.
- Will the cost increase in the next year. Google (including google cloud) has a reputation for a reason.
- Here we have seen time and time again problems reaching support with Google Cloud.
Meanwhile my personal AWS account that I spend maybe $5 a month on... I emailed support about a billing problem and got a response about a day later.
I would not risk my job by using Google Cloud and being at the whims of Google being Google. The last thing I want is to have to go to my leadership and explain why the cost is going up or why suddenly we need to spend a bunch of engineering effort because google is discontinuing something.
If I really didn't want to support AWS/Amazon (which is fair) I would go Azure long before going GCloud. Hell I might be convinced to go IBM but thankfully I don't have to make that decision with Azure.
Nailed it. When we've had problems with AWS, I could drop our rep an email and be on a conference call with the engineers who run the service a day later. That not for a giant account, either.
They'd also periodically reach out to offer free consulting services that would cut our monthly bill. They were upfront about the motivation: they wanted us to integrate more of their services. The upside for us was that we could get better, cheaper service. If you're planning on sticking with them anyway, that's a very attractive offer.
Meanwhile, the support venue for our enterprise Google Workspace account was a mutual support web forum as far as I could tell.
Unless you've experienced both, it's hard to believe how radically differently the 2 companies handle customer support.
A previous client was all-in on GCP. They were not a huge operation and in fact were slowly migrating on-prem stuff to it. GCP support was pretty good. The account manager was always on point and whenever we needed we could have an actual engineer or two on a call with us to troubleshoot stuff and give us advice and general support.
Of course, for less urgent and less severe issues it would generally be done over the course of a couple days to a week in support ticket messages / email but that was perfectly fine.
I've been back to using AWS for a little while now and I miss how much simpler it is to set up things in GCP. Even IAM which I remember bitching about so much during those days, now I just miss how much simpler it was and I didn't realise.
Also if you need Kubernetes, no other offering compares to GKE.
The argument being stated multiple times doesn't mean it is valid.
Amazon, Microsoft and Google have all launched roughly as many products in the last couple of decades, and killed roughly as many of them unceremoniously after the products failed. (Amazon execs used to outright brag to the media about how many products they killed, since it showed that they were daring to take risks.)
AWS, Azure and GCP have also all launched roughly the same product portfolios, and each of them killed basically none of those products.
Sure, sure. I totally get where you're coming from.
By the way, how's the Fire Phone holding up for you these days? I assume it's still working well and powerful enough to do your web searches on a9.com, and read sites like the Amapedia and DPReviews. Do you happen to know how many of the Alexa.com top500 sites it can browse, or do you need to ask on Amazon Askville? But I know it won't be able to play Amazon's hit game Crucible, that's a PC game!
If you need to play some tunes on your Amazon Tap speaker and don't have them on the phone, all your mp3s are right there on Amazon Music Storage, just where you left them with the Amazon Music Importer to be played with the Amazon Cloud Player. And the files are safely backed up on Amazon Drive just in case! It's the same thing with all the digital movies you bought on Amazon Unbox, they'll just be waiting in the cloud for you to download them. (Watching DVDs rented from LoveFilm is just so yesterday.) [0]
And let's not forget Amazon's initial core competency of retail!
Just use your Dash Button to order some more books from Book Depository, it'd be a bother to have to go to one of the physical Amazon Books stores. It's just crazy how much stuff you can buy online these days! Shoes from endless.com, food delivered straight to your doorstep by Amazon Restaurants, concert tickets from Amazon Tickets, flash fashion from MyHabit.com, hotel bookings from Amazon Destinations, and all kinds of daily necessities for the family from places like diapers.com and soap.com. And don't worry, if you're bored of these normal online stores (like those set up with Amazon Webstore) and want a different experience, there's always Amazon Spark or Amazon Light for fresh takes on shopping! And for the really rare stuff, there's a good chance that there's some listings on Amazon Auction. Really, the only time I have to deal with local businesses is when I get one of those amazing group deals from Amazon Local (the code for that can surely be stored in Amazon Wallet).
I wonder what the right way to pay in one of those local stores is though... Will they take Amazon WebPay, or will I need to have my credit card scanned by one of those Amazon Local Register payment terminals?
But let's not think that it's all about consumption. I'm actually working on a screenplay myself, using Amazon Storywriter! Once I get it printed using BookSurge, it'll look professional af.
Those are almost (if not all) consumer facing products. I get it though - most of the complaints leveled at Google relate to their shutting down of consumer facing products. What's Google's track record for removing cloud infrastructure services? In the context of this thread, that comparison would be interesting.
Google recently killed an important firebase feature around cross platform in-app links, not raise prices, no
KILL IT.
It’s a feature depended on by tons and tons of customers, that was a far bigger shock for me than google domains, atleast domain infra is designed with migration in mind usually (dns not included)
But google killing of a vital feature[1] of firebase (with no google alternative provided) made me shit scared on if I should integrate with more of their products.
They also randomly jacked up prices of sms authentication exponentially in a day without any major notice and caused a ton of people to get thousands of dollars in bill increase suddenly [2].
Stay away from google is a good idea unless playing russian roulette at work is your hobby.
Every product there is one manager’s ambition for promotion away from being killed and re-invented
No, we aren't. Everybody complaining about Google having a reputation for killing products is talking about their consumer products.
In fact, if you read just a few posts up, you'll see that in my first message I made the exact point about how Amazon!=AWS just like Google!=GCP. And the rebuttal was that Amazon actually rarely kills products. That's what I was replying to.
If you want to say that Amazon's track record is irrelevant to AWS, just be consistent and apply the same reasoning to Azure and GCP.
I've been watching folks here on HN speculate that Google will kill GCP "any minute now" for at least the last 4 years, so ya'll can keep holding your breath, I will be having fun deploying things for 1/10th the price of AWS.
> However my style and approach to problems is more in alignment with GCP. I am for example of the opinion that the cloud provider should take care of everything linked to infrastructure, maintenance and as well scaling.
You get that on AWS, too. The difference in my experience has been that once you’re out of a narrow range of features you’re more likely to hit something which is builtin on AWS but has a GCP ticket from 5 years ago with no progress. If you have any kind of security compliance requirements that gets brutal on GCP since you have to take on running an entire service to get that one missing feature.
GCP is overall a good product. Support is so atrocious and they break things often enough that it more than offsets that in any larger scale use case in my experience.
If it can't get profitable (or at least within $1B/year of profitable, or have some sort of major loss leader value to Google) then I'd give it 90% likelihood they they announce a shutdown within 10 years.
Whether or not they'll continue to lose billions a year for Google I can't say.
If they do want to kill it, I can see them giving as little as a 5 year window before everything is shut down.
Odds? Nobody's a fortune teller, but it was still being subsidized by ads with 3B loss in its FY22[0 p. 70], only increasing 100M in profit despite cloud revenue growing from 19B to 26B overall [0 p. 66]. They're either going to need to increase costs or add more "killer" products with large margins if they want to become profitable.
At what odds are you willing to make a bet on this? Do you think there's a 20% chance it's gone in 5 years? Do you think it's 5%? Do you think it's 30%?
People keep saying things will be shut down and I think they should put their money where their mouth is.
A 5% chance of needing to do a migration in 10 years is very small in comparison to other technical risks.
And lets be clear, this is not a catastrophic risk; your contract with GCP guarantees they will not discontinue services without 12 months of notice so you will have time to do an orderly migration unless Alphabet itself goes under.
I am a GCP user; I have found their offering (actually having GPU quota) significantly better than the other clouds and GCP shutting down does not keep me up at all.
12 months notice is too short for big non-tech enterprises. They plan their infrastructure needs in 5-year terms. Changing to a new environment takes re-educating a lot of people, going through a lot of legal and audit meetings, finding enough manpower to do the transfer, putting things on hold purely for the migration,...
12 months is the time for the contracts to settle between these enterprises and cloud-vendors.
If your company is that big and unwieldy that a tiny chance of needing to do a migration in 12 months is unacceptable, you can stick to the key services which offer 36 months of notice. For all I know at that point you can negotiate your own guarantee if you're so big.
If you work at a company that can't do a cloud infra migration in 36 months, I don't have any good advice for you, but I doubt most commenters on here fall into that bucket. Frankly, I would expect companies that large to be in all the clouds so that you could negotiate them against each other, but I doubt that impacts many people here, and the chance of any of these worst case scenarios happening is vanishingly small.
This isn't a tiny change, if GCloud says "we quit in a year". That is a huge change. Applications using GCloud SDK for services suddenly need to be reworked and redrawn. That alone is a huge change for non-tech companies.
Some companies even need to check with the laws they reside in if the new cloud vendor can even be used.
Just work in any financial, medical, pharmaceutical, government-related... company and you'll understand that a year is nothing for these companies.
What an oddly aggressive comment - perhaps the problem isn't prediction but extrapolation of past experiences with Google, would you not agree that it gives you a sliver of worry that they may cut the service off?
You seem very intense about Google's offering, maybe you feel attacked by the points made in the thread, but the way you're approaching this discussion is very strange.
I'm tired of reading the same thing over and over where people prognosticate based on poor readings of events and I think people should put there money where their mouth is.
I really do not think the chance of GCP discontinuing a core service is high enough to warrant the level of comments this gets and if I find myself constantly reading these comments, maybe I can at least be compensated by people making bad bets or maybe people will admit the chance is really low.
So if you are so worried about this, please give me a number that represents how worried you are about this.
It is not a core cloud service, it is a service for a niche industry that never met the hype it had and probably didn't get many customers.
I don't think discontinuing cloud iot provides any indication that compute engine is going away.
AFAICT cloud iot core was hosted mqtt, which is a thing others offer and you can transition relatively easily. I don't think the shutdown of it was catastrophic for any companies; the quotes I saw in articles were of the sort "yeah, that's annoying, but it shouldn't be hard to migrate to something else".
Eridrus used to work at Google. Not sure if it would be good to disclose before aggressively asking people to bet on the lifespan of Google products, I certainly would err on the side of disclosing.
I used to work in cloud security, mostly AWS but got to hear about experiences with GCP.
AWS IAM is much better than GCP, or was 3 years ago. If you are in an industry where fine-tuned RBAC per service is a thing you want, it's better to go AWS, all things equal.
Also, GCP reps suck compared to AWS in terms of responsiveness and general give-a-shits. Hearsay.
Yeah, no. GCP actually allows you to give developers full permissions on their project. This sort of separation doesn't exist on AWS, at least not without making it very hard to impossible to share resources. So on AWS, you either have a really good platform team that handles permissions / terraform review / all infra setup (unlikely), a bad or understaffed team doing the same so everyone waits a week or two on specific things being set up (and everyone will hate them for killing their velocity), or you let everyone run wild with way too many permissions so they can actually use the console, hoping they'll stick to best practices (they wouldn't). At least developers doing unsafe things is contained in GCP.
But all that aside, AWS is better. It's much more predictable which things will work together from the documentation, the support is better and the IAM is better on paper, if you actually have that unicorn platform/infrastructure team.
My biggest challenge with GCP is that I'm still not convinced Google cares that much about this division.
They acquired Looker, fired the customer service staff, and then set it out to crumble. Looker used to be LOVED by its customers but now they were forced to make their semantic layer work with Tableau.
Also, I'm still not convinced Google cares about divisions that aren't linked to advertising. Google Search, Gmail (kinda), Maps, Android, and YouTube are their darlings.
Will GCP be around in 5 years? I honestly am not sure.
I used to work in GCP. They are definitely committed to it. Search, Android, Google Cloud, YouTube - definitely committed.
It's the random little things they build too many of and hence close down. They never really understood branding. Slapping Google on everything doesn't help, it hurts. Many things are actually experiments and shouldn't be marketed as more than that.
October 2019 - "It is a long term view that Google is taking"
November 2020 - "roadmap of about 400 games in development right now from 200 developers [...] 2023 is really kind of where we’re aiming our sights"
February 2021 - "building Stadia into a long-term, sustainable business [...] remain committed to Stadia as a platform"
September 2021 - "gaming is an incredibly important vertical at Google"
November 2021 - "eager to continue working on bringing the best games and new features to our community of players so that we can help build a bright future for cloud gaming"
February 2022 - "we are still focused on bringing great games to Stadia in 2022 [...] more feature goodness coming to Stadia too - stuff we can’t talk about just yet"
September 2022 - "You might have seen one last game arrive on Stadia today. It's a humble :heart: thanks :heart: for playing from our team."
"With respect to the upcoming Gmail announcement, there are no changes to Inbox by Gmail. It remains a great product for users with specific workflows and one in which we test innovative features for email."
Didn't Microsoft just spend a year in court with their top VPs & CEO fighting against the UK & US governments over cloud gaming so that they could buy Activision for roughly $70 billion?
I believe they had to make concessions with the UK to somewhat outsource the cloud gaming aspect of the deal so that it could go through. This was something they didn't seem to want to do but also forced them to extend their merger & pay additional dividends to shareholders of Activision.
It may have been a component, but no, the fight was over Call of Duty becoming an Xbox Exclusive Title, instead of being generally available on all platforms, including Playstation.
The market is tiny (relatively) for all of these players. Motley Fool estimates the entire cloud gaming industry is ~$2.5B in total revenue for 2023.
Many of the current services are likely running at a loss, hoping for the hype-train to get people into it.
The reality is, most people wanting to play AAA titles either have a console, or a gaming computer already
The cross-section of people with a 10 year old macbook, that want to play the latest AAA title, have expensive high-bandwidth internet, and are willing to pay ~$30+ a month is just not that large.
I'm sorry what does any of this have to do with Google's lies with regards to their commitment to cloud gaming? All gaming platforms run at a loss in their early days.
> The cross-section of people with a 10 year old macbook, that want to play the latest AAA title, have expensive high-bandwidth internet, and are willing to pay ~$30+ a month is just not that large.
This is frankly an idiotic summary of what you believe to be the cloud gaming addressable market.
> I'm sorry what does any of this have to do with Google's lies
Google is not a charity. If something is not working out financially, or the market has failed to grow at the pace Google initially thought, it is in their best interest to exit that market and re-allocate resources. You know... like any rational business.
> This is frankly an idiotic summary
Well then perhaps you can enlighten us on why the market has failed to materialize? $2.5B for 4+ industry-heavyweights to fight over is pathetically small.
The R&D costs alone to deliver this type of service likely outweigh several years of total industry revenue... yet each of these companies is trying to blaze their own path more-or-less independently.
In short, there is no addressable market, and the numbers clearly tell us that. Do not be surprised when more of the players exit this market as well.
Just because you love a service doesn't make it a reasonable or sustainable offering.
> If something is not working out financially, or the market has failed to grow at the pace Google initially thought, it is in their best interest to exit that market and re-allocate resources.
Correct, Google can't be trusted to commit to a product long-term. Even a product with paying customers.
> Well then perhaps you can enlighten us on why the market has failed to materialize?
Because like I said, it's a young market. It has absolutely enormous upsides for those that can win it.
> there is no addressable market
This is laughable. You're a clown.
> Just because you love a service
None of the cloud gaming vendors have ever even offered the service in my country. I have no dog in this hunt.
You don't seem to be capable of understanding basics about business and seem to feel entitled to services that aren't working...
It's no wonder you're so upset.
You still cannot explain where the market is, or why the existing services are being forced to raise prices and cut hours already... but hey, you want it therefore you're owed it, right?
You're misunderstanding the limit on gaming subscription revenue from having to put a $400 and usually idle P55 or XSX in every living room instead of leverage a free app already in every TV.
I honestly believe the market will get there eventually, it's a lot easier for a teen to justify a 18 dollar subscription to a parent than a 400 dollar console/PC
The problem is it's $18 today, during a period of loss leading behavior from the incumbents. When this technology needs to become profitable, it'll be vastly more expensive than it currently is. ie. the "Uber" effect.
Think about it... exclusive access to a 4090 GPU for up to 5-8 hours a day for $18? Isn't going to happen. The electricity alone will cost more than that to operate over a month.
That does not even factor in a relatively expensive high-bandwidth internet connection that a lot of the world doesn't have... and you still need a device capable of consuming 1080p, 1440p, or 4K content in near realtime - ie. it still has to be a relatively capable system.
The economics are dubious, to say the least. Emerging markets without a lot of average household disposable income is probably where this type of service will excel - and even there we're already seeing price increases and cuts to maximum daily playable hours.
It is 100% fair because it supports a trend. Amazon didn’t have to continue support for a myriad of AWS products yet still do and maintain backwards compatibility.
Google very clearly stated in no uncertain terms that Stadia was a real product that they were committed to for the long term. Stating, after the fact, that it was "actually" an "experiment" or a "random little thing" is not just dismissive - it's pure revisionist history.
Yeah... Google employees just _do_ that sort of shitty redirection, and it's obnoxious as fuck.
Maybe it works in a "We're too polite to disrupt whatever political game you're playing in the hopes that you'll reciprocate when we splash obvious bullshit when we play ours." snakepit that seems to be most of Google, but out here, we're unchained by that political nonsense.
Bonus chatter: We get that you'd like die for your coworkers or whatever, but as people who have no social (or political) investment in either the services or how they're made, these "But they're run by GOOD, PASSIONATE people! I have personal experience with this!" appeals are simply irrelevant.
No one is saying Google has broken contracts or the law. What is it with you Google defenders and your constant goalpost shifting? We are saying, Google is not to be trusted with claims like "we are committed to this product" because they have been caught in that lie several times before. Why are you going on about contract law and "most people and companies"? What you're saying is irrelevant.
The point is: don't expect companies or people to act against their interests. They generally haven't, don't and won't. Google isn't unique here. The problem is so pervasive in society that humans created contracts and courts to force people/companies to do things they wouldn't otherwise do.
What folks at google think and what they say publicly aren't the same thing. It's naive to think otherwise. Look to what actually makes sense for them to do and you'll have your answer.
Internal folks knew google would walk away in a few years if it didn't work. Stadia was largely a group of people out of the failed and left behind Daydream (VR) project.
So why are we to believe statements that GCP is here to stay? They are, after all, statements to customers who need to hear it to make the purchase. But who knows how they actually think?
The whole reason why Google cannot be trusted here is precisely because of their tendency to be inauthentic in their public statements.
I wouldn't believe anything they say. Just look at the numbers. They aren't going to walk away from a business doing about $35 billion per year run rate, growing at 20%+. It isn't in their interest to do so.
"Internal folks" who gives a rats ass about what they think? A company's reputation has little to do with how people on the inside perceive it, its actions and track record do the talking.
Stadia was a classic reason I couldn't trust GCP or any Google product aside from Gmail cause I've been using it so long, because unlike you I'm NOT in the know, I just see a bunch of stuff spun out, hyped (calling it 'little stuff' is a highly subjective assertion) and axed without warning. And I won't mention what an absolute mess the android development journey has been, a related symptom of a haphazard, disorganized product strategy. These things are uniquely Google, and it's a terrible look.
Agree, nobody cares. But it was pointed out in response to a suggestion it's revisionist to say it was an experiment. It was correct (ie it was an experiment), albeit not understood by people who believe at face value what companies say.
I haven't been in the know for years, but I learned enough - don't look at what they say, look at where the money is. It's the same for almost every company.
Product strategy is a mess at most companies. The developer experience sucks for most products. Stripe built a multi-billion dollar business off of developer experience because the standard experience sucks so bad.
i dont doubt gcp will continue existing. but individual services/products/apis/pricing break way too frequently, and the response from google is deal with it. small companies dont really notice it, and how anti-customer it is, but when once a month youre dealing with some firefight because gcp decided to change something its tiring, since at a big company it means tracking down ten different teams. ive not experienced anywhere near the churn in aws
Google making AppEngine in the first place always felt weird to me. It was great for some web developers, but outside that use case, really not so much. But it came with a great collection of side technologies, which got unbundled (Datastore, etc) because there were folks (like me) who wanted to use the side tech but not AE itself (for many, many years you couldn't "import numpy" but people would still say "see? We have a cloud, it's called AppEngine").
Once enough things were unbundled from AE, and containers became popular, it wasn't really clear what AE provided that wasn't better solved by more standard tech.
Often times, Google leadership simply didn't understand what its own engineers and product managers knew. People told me for years "we can't do cloud because the profit margins are too small", and now look: Google is a perenially third-place in Cloud but has committed itself so much they can't even shut it down if they want to.
No, we all just migrated the decision of using GAE to using Cloud Functions / Run / Tasks, which is fine. Those are easier for Google to scale over time, than AppEngine.
The problem with AppEngine was that they had to heavily modify the runtimes for isolation... the JVM needed to be secured and that meant maintaining a separate fork, which also meant being perpetually always behind in versions. It also meant any upgrade had to go through a huge security evaluation.
So, moving to another process model, containers, worked much better.
My best friend Jeff started working on Objectify in 2009 after I convinced him to use GAE. I have built two businesses on it. One did $80m in revenue in the first year and I guarantee we couldn’t have done it without GAE.
Ugh, now you're making me explain myself due to your poor understanding of what I was saying and taking different comments in different threads out of context.
"We migrated"... meaning that over time, everyone is migrating from the concept of using GAE as a first choice, to using things like Run/Functions. Not that I actually physically took code for GAE and moved it to R/F. For example, my last project, I choose to use GCF, instead of GAE. The reason I went straight to GCF is because it is effectively what GAE has morphed into today. This isn't a slight on GAE at all. I've updated previous comment to hopefully clarify this for you.
Again, I have used GCP extensively since about 2009. By the way, much of what you use today was a result of things I did back when I co-founded the Jakarta Apache project, open sourced Tomcat from Sun, brought Lucene under the umbrella, blah blah blah... I've been around the internet since 1991.
Yea, they deprecated something. I even noted that the market is small for it in the thread. I built another solution in a short amount of time, and even gave it away because it really wasn't something people were using a lot of. It was a super niche product. That also wasn't even AppEngine, it was just a nice to have, for me, sub-service.
There was a point where people were upset about GCP and Google changed their whole deprecation policies to be more vocal and longer term about things.
I really don't understand your point. What's the big deal?
A better question is whether it’ll have improved or had price increases. GCP has had a bunch of increases lately, and you never know what will be next so you always have to guess at whether you’ll regret locking yourself more to a proprietary service.
I generally prefer AWS except for the good experience I've had with cloud run, but GCP getting shut down is not something I would worry about. These cloud services are highly profitable
Google has closed time after time things that were profitable and/or loved by their customer. At this point I don't see how anyone would be willing to bet the farm on anything Google
GCP is theoretically superior because it has more features and integrations built in. But in practice it's a big mess, and if you want to do anything the "not GCP way", you're better off just not using it at all. People talk about GCP "getting X right", which might be true, except to actually use the thing that they "got right" you have to use everything else they have, and good luck figuring out how to do that with their insanely bad/missing docs. Let's not even get into how they overload the same concept in multiple places, have tons of arbitrary limitations of naming conventions for different components, navigating the console is a pain (and again arbitrarily limiting), and services are weirdly implemented so the SDK is inconsistent. They tried really hard to pretend they had some unified, Enterprise-ready, perfect system/design, and of course failed at implementation, because perfect systems don't exist. Their support is crap and their services are down a lot, and very slow to orchestrate.
AWS is less feature-filled by default, but everything that is there works, isn't complicated, can be used a-la-carte, and docs are easy to find. Support is insanely reliable. They take a one-useful-piece-at-a-time approach rather than making you use the kitchen sink, and it's not hard to get things working (well, not any harder than for any other cloud provider). Pretty much everything they do is simpler and more reliable.
I've had nearly the opposite experience, except for support where I've had good and bad experiences with both AWS and GCP. I never understood why people love AWS support so much, it seemed pretty "meh" and I've heard from friends who have had truly awful experiences with paid support for security issues.
In my experience, GCP has a solid, easy, happy-path, and reasonable options for the more esoteric use-cases. AWS typically had a happy path that was clearly poor engineering/dev-ops practice, and more esoteric use-cases required gross hacks and either worked or threw weird errors that suggested it was a pile of shell scripts under the hood.
Everyone will have different experiences with this of course, but product excellence is not an advantage of AWS that I hear from people, it's always support, or pricing, or contracts.
Can you be more specific?
I experience no problems navigating the GCP Console UI.
Though I mostly do not do it -- I have stuctured bookmarklets for everything I use and it works really great. And also I use gcloud and Terraform a lot.
I have very little experience with GCP as not much of an infra person. However, for me the most annoying bit is how the profiler is using its welcome screen as a loading indicator as well as 'there is no data' page. Makes it very hard to browse data.
I think YRMV depending on what you're trying to do, but I think the DX & web console experience is much more pleasant on GCP.
On GCP, their services are cleanly organized and have distinct icons that tell me what it does with minimal reading. On AWS, often I'm left scratching my head (see https://awsiconquiz.com/)
The web console design on AWS is catching up (for a long time the UI just looked like an offshoot of the e-commerce site design and wasn't very clean) to GCP, but occasionally you still find elements of the old AWS console design.
Often, it seems like AWS has more leaky abstractions that require you to be more aware of all the other connecting components of their infra services.
For example, trying running managed Airflow on AWS/GCP. Both services require some VPC & storage infra setup to get your Airflow container services running. On GCP, you can spin up Cloud Composer without specifying your VPC or storage bucket details and they'll default them for you.
AWS however, you'll need to have your VPC/S3 already setup ahead and if you've not configured your private/public subnets or S3 IAM policy, you can put your Airflow environment into a non-workable state.
Overall, I think GCP has some advantages of not being saddled with legacy baggage that AWS has with making sure their services are interoperable.
I agree - Kubernetes on AWS was a bit of a shock after using it on GCP (yay) and Azure (meh). I think it makes sense if you've used AWS for a while, and know the security groups etc dance, but it was a bit jarring.
Google recently killed an important firebase feature around cross platform in-app links, not raise prices, no
KILL IT. It’s a feature depended on by tons and tons of customers, that was a far bigger shock for me than google domains, atleast domain infra is designed with migration in mind usually (dns not included)
But google killing of a vital feature[1] of firebase (with no google alternative provided) made me shit scared on if I should integrate with more of their products.
They also randomly jacked up prices of sms authentication exponentially in a day without any major notice and caused a ton of people to get thousands of dollars in bill increase suddenly [2].
Staying away from google is a good idea unless playing russian roulette at work is your hobby.
Every product there, is one manager’s ambition for promotion away from being killed and re-invented
To everyone saying GCP will be gone - it generates over $8 billion in revenue per year and $400 million in profit. There's no chance they kill it any time soon.
Yes it posted heavy losses in the past, but any major infrastructure does, and obviously there is a major amount of potential - and they have around 10% of the total cloud market share, not insignificant by any means.
One correction. It's not $8B per year, it's $8.4B in the last quarter--which is over $32B annualized, especially considering the last quarter's revenue grew over 20% from the same time last year. GCP's profit margins are low (for now) but positive. [1]
Moreover, per its filings, Google had almost $65B of contracted backlog representing customer commitments for future purchases (over multiple years), primarily related to Google Cloud. That is not to say those can't ever be unwound or delayed, but it's a pretty meaningful amount, even to a company the size of Google. [2]
I find the GCP documentation to be lacking compared to AWS. Specifically while using GCP with Terraform I hit more frustrating nonsense error messages with little to no google hits or undocumented behavior around IAM config compared to my experience doing similar things on AWS.
I'm a technical writing manager on GCP, and we are actively working on improving Terraform documentation. Thank you for bringing up two significant problems with using TF on GCP.
If you are willing (and of course have the time), we would love to hear other issues you - or anyone else who reads this thread - are having with TF documentation on GCP as we try and make things better.
Rinse and repeat - someone complains about cloud provider, a cloud provider person shows up and makes a "we want to hear more about your problems" statement, people reply, they do nothing. How many times has this happened? I'm more disgusted by the farce than by the lack of action.
Don't you have feedback buttons on the docs? What happens to the feedback from those? Please prove you consider feedback before asking people for more of it.
A few months ago I was working on migrating cloud build for a personal project and hit a documentation error. Submitted a correction via the feedback button and it got fixed few days later. To be honest I was a little surprised by how fast it got fixed.
A general issue I have with GCP docs is that they are overly implicit. Often the interaction of two features is implied but not specified. Another issue I have is when implementation details are waved away rather than explained. It adds up to an experience where I am trying to read between the lines of the GCP docs for a feature to understand what is really happening.
AWS docs are the opposite. They are often very long and verbose, but once you read the whole manual, you can be guaranteed to have a good understanding of the service.
My advice for the Google team would be that if you are ever writing documentation and ask yourself “does the customer really need to know about this?”, the answer should always be yes.
This is probably more a request at the compute team/gke teams but...spot management.
For example, managing a spot fleet in AWS via terraform is filled with features and levers I can pull. It's easy to manage basic scale-out/scale-in procedures and allows me to set thresholds.
In GCP, as I understand it, I can only manage a node pool at a basic level.
EDIT: Also, yell at the people who manage the python library.
Can you please update the terraform docs for google batch? In [1] it’s really difficult to know what everything in the json configuration is under the base64encode() call. What levers can I pull? How do I run something more complex than hello world? Do I need my CICD to upload scripts to GCS and have the instance download them at runtime and hardcode that path into the batch script?
It seems as though Google Batch does not have a native Terraform resource. The document in [1] seems like a workaround that leverages the Cloud Scheduler Terraform resource, but submit a job using the JSON configuration. The various fields that can be used in the JSON are within [2]. Regarding using GCS there is an example in [3]. I found more samples in [4]
I had the same gripe when I worked with GCP. Their stuff is exotic, and had weird behaviors in corners, but the docs didn't give you enough context to steer away from them.
However, over the last 5 years or so, AWS docs have gotten worse.
So I guess now that they are both bad I can't complain?
Did they? Do you have an example at hand? We ran into "weird" issues a lot of times with AWS services just to discover afterwards that almost all of them were covered by their documentation.
It was totally our fault and these were also no "hidden" docs.
100%. My experience has been the same. The docs have their shortcomings and I ended up reading through so many Github issues and random blog posts trying to resolve the issues.
From a documentation perspective, AWS is still the best.
Wow I would literally say the opposite. I even use GCP docs as an example for my engineers on how to write proper docs, and did several workshops using the GCP docs as reference. Happy to share the presentation if interested.
Google's support is the worst. Have an issue like those random nonsense error messages, good luck getting it resolved. AWS is complete the opposite. I had an issue Aurora Postgres and got to chat with the product manager of the product.
Google could have the best products on the market but no one is going to use them if the support isn't there.
I was sad when Looker got bought by google. I remember having issues with setting up looker and using their chat functionality and having the CEO of Looker answer my question.
Well, AIUI "reach the front page of HN" was always the only cited way of getting any help with a Google problem, so in that way this is a derivative of that scenario
I've used GCP support on accounts with huge support contracts and enterprise agreements and it's still a bit of a wash if you get good support on your first, second or even third run around the reply button.
At least it isn't (paid) Azure Support - that one is noticeably outsourced to people that sometimes lack basic comprehension for the problem. I once asked about their VPN Gateway and got a random API Gateway response, then nothing for a week, and then a new rep.
Why is GCP a distance 3rd with cloud providers? They used to be second. They literally will throw tens of thousands of dollars of free development to get you to switch. Amazon may give some service credits if you're willing to switch an application over to them. EKS and GKE are on par with each other. So its not technology holding them back.
Honestly, it boggles my mind. Bad marketing seems to be the driving force here.
“Nobody ever gets fired for buying IBM.”
If you've actually spent time building on their platform though, it feels like you're in some sort of inner circle of knowledge. The stuff works, and works really well.
Could you elaborate on the accounting part? I'm deeply involved with billing on all three and while AWS seems to have all the data you're looking for in the CUR, it can be a multi-quarter job to build up the expertise to understand that fact.
GCP has different notions, like multiple credits applying to any given charge but again once you build up the expertise you can work with it. Azure seems by far the simplest to deal with and require the least wrangling.
Shameless plug: At the company I work for (meshcloud) we have developed a freely available model that describes the capabilities your central team is building up: https://cloudfoundation.org/maturity-model/
Disclaimer: meshcloud sells a product for teams in that space
I don't buy the article's argument around the "Fear that GCP may be abandoned by Google". Yes, it is highly unlikely that Google will wake-up one day and announce a deprecation day for GCP, like they did with dozens of other products. What is not unlikely though is that they under-invest in it compared to AWS, and being a 2nd or 3rd player, they would fall behind in products and/or reliability, unable to compete on price or features due to better economies of scale of the competitors.
Before Google kills products, they lose interest in them.
It can create problems from a different angle, though. Google might lock your account for no reason for a week, without any explanation. If that happens, it's your problem if you lose your whole business after a week of downtime. Since it's Google, you can't even contact support.
This has happened to me a couple of times. Once, my account was locked for a day because their system flagged one of my servers for suspicious traffic. They locked all my servers, databases, and everything else, not just that one server. Another time, they locked a different project for a week. It actually took me a week to find a human who could unlock it; otherwise, it could have been even longer. I still don't know the reason for the lock.
So the main problem is that Google don't care about GCP at all, and threat paid customers in same way as free users (i.e., hostile to both)
GCP doesn't really have the Google problem of lacking support contacts. I've managed relationships with GCP for a couple of different companies now (from startup to mid-size enterprise), and in all cases I had multiple dedicated account reps that I could not only get on a phone, but frequently met with in person.
Maybe the story is different for very very small fish, but I had decent experiences with support even at the ~20-person company spending ~5k/month level.
My company spends maybe $4k/mo with GCP, and I have absolutely no idea who my "dedicated account rep" is. I did have someone contact me way back when, but after finding out we aren't VC funded they literally ghosted me.
I don't really enjoy being on GCP for that reason, but I need it for BigQuery, so...
After the last incident (with a week of downtime) I learned that they have a paid support, which you have to sign up in advance so it didn't work for us at that moment.
Now we signed up for it, though I still not sure how it works and how I supposed to contact them in case of an emergency. All I see they charge us something for that support agreement, hope I will never need it.
Not in my experience, unfortunately. The reps we got with GCP could give us advice, but no real powers to push stuff or solve problems, it felt more like L1 support. As described bellow, maybe it depends on a company size and/or a country.
Not going to happen; they kill consumer- not enterprise products. I searched https://killedbygoogle.com/ for "Google Cloud" and the only dead enterprise products that stood out were Google Cloud Messaging and Google Cloud Prediction API. But they replaced those with Firebase Cloud Messaging and the AI Platform Prediction API.
Technology isn't a weakness with Google... never was. Most of their stuff is top-notch technology-wise. The problems are from a business-angle and being their customer.
Meaning, even if you're a F500 company you are an insignificant gnat on the windshield of the gigantic G-machine that makes its money elsewhere.
Now, I don't believe think they'd actually shut GCP down. Cloud is just too damn strategic in a post Y2k world.
Complain about Amazon if you wish, and there are many reasons to. They are not as tech-oriented and the task-master culture of Bezos is well-known by now. But at the very least they are sales and customer focused, and retail and cloud is where they make their money. So incentives are better aligned with them. Even if their customer service is not amazing, the fact that it actually exists is a large factor in their favor.
> Technology isn't a weakness with Google... never was. Most of their stuff is top-notch technology-wise. The problems are from a business-angle and being their customer.
There's very little technologically impressive with GCP. It's the same products from all three vendors with few exceptions.
What's a clear weakness with GCP is Google's lack of seriousness as operators. Regions in the same data center, outages that take down a whole region for 3+ days. It's not good.
I remember early on G was doing several second billing, while AWS was on minutes. There are other things like better performance, authoring K8s and http2/3 etc that gave them the edge. AWS was earlier and had greater breadth of course.
With even a medium level investment in AWS, I can get actual human people from Amazon on my company Slack on a channel and I can talk to them directly. I can get them to fly to our office to train people or workshop on how to use the resources more effectively.
On GCP I get some AI bot that doesn't answer anything and if I anger it by accident, my account and my business is gone. Then my only option is getting on the HN front page to get some help.
i’ve built bespoke automation at the api level for azure, gcp, and aws.
using azure makes you want to watch the world burn.
using gcp makes you want to give alcoholism a fair try.
using aws makes you wonder why we can’t have nice things.
ime those who prefer gcp tend to use a web interface. those who don’t have a preference tend to use iac. you want to work directly with the api, for innumerable reasons.
aws is the canonical example of use boring tech. nobody cares which database you use, not even a little. if you’re talking about your stack choices, your product likely has negative value.
of all the projects i pull into my rss reader, github commits on the aws-go-sdk-v1 are the most consistent and unsurprising. ive been following aws api and service changes since boto1.
there’s a lot i wish was different about aws, but nothing that’s urgent.
someday we’ll get better providers. it won’t be azure or gcp. it will be a new player.
by 2030 i’d expect to see someone disrupting aws by offering api compatible clones of the core services without egress fees. r53, dynamo, ec2, ec2 spot, lambda, s3, apigateway, sqs.
I defer to your expertise, esp when it comes to actually using these different services at scale, but as someone who used to deploy only to Heroku and wanted to learn real cloud deployment, AWS was pretty unapproachable. I almost laughed out loud at how unnecessarily arcane and difficult they made things when all I wanted to do was set up a simple Python app on EC2.
Google Cloud felt easier and intuitive to get started with, so that's what I use now.
GCP has some nice things but AWS is simply more reliable.
The GCP outage [1] in April is a great example. A fire in europe-west9-a "zone" took down the entire europe-west9 "region" (because this entire "region" is actually housed in a single datacenter), which then caused a global GCP console/API outage because GCP's single global control plane couldn't reach europe-west9.
The fact that a zonal issue escalated to a regional and then global outage shows that GCP is not serious about limiting blast radius and all their talk of independent regional/zonal infrastructure is marketing fluff.
In comparison, AWS AZs can be up to 60 miles apart, share no physical infrastructure, and every region hosts its own API/console/control plane.
Also, Nitro. AWS has essentially eliminated the performance overhead of virtualization with Nitro, and years later GCP still has no equivalent so GCP customers still have to pay for that overhead.
GCP does not have a single global control plane. Each product has a separate control plane, and many/most of those are regional. GCE (Compute) does have a global control plane today.
The GCP Console, unlike other cloud providers, displays an aggregated view over all the regions. That means calling the control plane for a particular service which then in turn will do fan-out to all regions and merge the results.
For example a page might call the GCE global control plane:
(Specifying the location would call that particular region though)
During the incident the small (but critical) subset of Console pages which needed aggregated data from GCE's global control plane failed to load.
I agree it's unacceptable that the Console doesn't handle regional failures more gracefully, and it's very much been a priority to improve region down handling.
> because this entire "region" is actually housed in a single datacenter
From the incident report you linked:
"a cooling system water pipe leak occurred in one of the data centers in the europe-west9 region [...] Europe-west9 contains three buildings with independent cooling, power, and networking"
Also,
> a global GCP console/API outage because GCP's single global control plane couldn't reach europe-west9.
again, from that page,
"A small number of methods within the GCE control plane API must collect information from multiple regions or zones by making requests to each regional control plane (called fanout requests). Google Cloud services including Cloud Console depend on these methods. When the GCE control plane for the europe-west9 region and zones went offline, some of these fanout methods did not operate correctly. During the outage, this led to global unavailability for some pages and control plane operations within Cloud Console"
It's certainly not great that a regional problem had global impact, but there is some nuance. For example, that paragraph talks about "each" regional control plane, in addition to a global control plane.
I don't mean to belittle the importance of the incident. Suffice it to say lessons were learned and follow-up changes were made.
The Compute Engine C3 machine series, now available in Private Preview, is the first VM in the public cloud with the 4th Gen Intel Xeon Scalable processor and with Google’s custom Intel IPU. C3 machine instances use offload hardware for more predictable and efficient compute, high-performance storage, and a programmable packet processing capability for low latency and accelerated, secure networking
My view is that there are areas where GCP is better and areas where AWS is better. AWS has a much bigger community, and better business continuity story. GCP has a better developer experience and more uniquely-amazing best-in-class products (e.g. Spanner, Cloud Run, BigQuery). In the end, I don't believe Google will shut down GCP.
At Coherence (withcoherence.com) - I'm a cofounder - we deliver a developer platform that lets use use either cloud in a developer-friendly way. It also gives you some protection against lock-in to either cloud.
In my opinion all of GCPs advantages are eliminated by the fact that it is a Google product and I wouldn’t want to trust my business/livelihood to google. And this is not just an opinion I share, it’s the opinion of the large company I work for
We are a Microsoft shop now but used to be an Amazon shop. We don't feel the same way about Amazon and Microsoft as Google. I've seen plenty of people post on here or Twitter about how they've been locked out of a Google account. When exploring LLM solutions Google wasn't even on the table and killedbygoogle was referenced in that company meeting. Sure there is a killed by Microsoft website but if you look at the Microsoft one it spans 34 years and 158 products, while Google's spans 17 years and includes 293.
That timeline alone gives me more confidence in Microsoft over Google. Personally there are only two products of Googles I feel comfortable relying on. Google Chrome and Go.
We still use AWS but it's been a couple years since I've really needed to dig into it because we have very competent people who'se job that is now.
My memories of having to find the right form, paste the right ID of the right server/bucket/lambda into are pretty traumatic. A TON of guesswork. Lot of what felt like duct taping things together.
If you don't have a full mental model of how everything works, they're certainly not going to help you get one without reading documentation. Their documentation is for the most part top tier, but the UX makes it more important than it arguably should be.
There's a difference between not handholding and just being obtuse, and I feel like so much of AWS's UI/general design philosophy falls into the latter camp.
Most of that stuff is far better managed with Terraform or similar as you have a record of which values go where that's mostly pretty easy to consume later. Using the console for anything beyond trivial admin is definitely an anti-pattern given how complicated the major cloud platforms are.
One fundamental difference between GCP and AWS is that AWS puts zones in different buildings in the same, well, "region," whereas GCP just isolated them in the same building.
Not the end of the world, but you shouldn't assume that by deploying things regionally with GCP you will be protected against, idk, a fire or water issue that has building-wide impact.
Who told you that GCP AZs typically coexist in the same building?
Can you provide the source of this information?
If you open for example one site of us-central1 region ( 41.17425599375981, -95.80193009453644 ) you will see that just this one site has several buildings.
I did a shootout of a number of cloud visual recognition APIs. All of them took less then 20 minutes to have a demo running except for GCP which rudely required me to install special software to log in which trashed the Python installation on my machine and overall took an order of magnitude more time than all the others... No thanks.
A lot of people (understandably) complain about longevity of various Google products. One thing that's nice about their overall cloud strategy is their focus on interoperability.
As the incumbents, AWS and Azure strive for lock-in. As the relative upstart, GCP aims to grease the wheels of switching to their platform. To that end, they've pioneered technologies like Kubernetes and the golang CDK to enable people implement their services in a vendor-agnostic way so they can easily switch around. GCP encourages that, which is nice, especially in the worst cases.
and, as an AWS-er having to now support GCP, I violently and emphatically disagree with this:
> The experience of GCP on the other hand is more like collecting the car keys and driving off from the parking lot, with the option of dismantling and customising the car if you wish, but the default is a fully built functioning car with cohesive parts so you can quickly achieve your objectives, which is driving around, not assemble the car.
Oh, really? I invite the GCP newcomer to click on https://console.cloud.google.com/ create a new Project, and then run $(gcloud functions list) or, as the sibling comment pointed out, $(gcloud run jobs list) and watch it cheerfully tell you that you must turn on those services for each and every Project. And not just cloudfunctions.googleapis.com or run.googleapis.com, it's for damn near everything a sane person would want to use cloud computing for
I reiterate: you cannot turn on those APIs for your GCP "account," you must do it for each and every Project you create
Oh, you're the Super Admin for your Google account? Well, be sure you grant yourself the resourcemanager.projectCreator Role because as super admin you don't automatically have it
A reasonable person may retort that these are "secure by design" by opt-ing-in to surface area and permissions that one wishes to have, but as compared to "create AWS Account, start using ELB like it ain't no thing and I have AdministratorAccess granting me * permissions" -- let's not start talking about collecting car keys and driving off the lot
I would be very afraid of automatic blocking of our entire infrastructure if some developer gets his Google account banned. No one (human) to provide support either, just automated responses.
Then the risk of some product being discontinued on Google is very real. The article just sidesteps it in the most unsatisfactory way, with a pinky promise that it won't happen.
So the technology itself is not bad, but Google's customer management is so terrible that I would never risk a company's life on it.
I don´t want to hate on the opinion of people, but "X is better then Y" is a pretty useless type of article.
I have used AWS, GCP and Azure + some more that offer AWS style of services. In the end the question is "what is best for my organisation?" It really really really does not matter if a developer finds GCP more easy to use or if AWS is way better at feature X.
The service has to fit the requirements.
And even worse, sometimes the requirements do not care for usability, cost or features.
While I never spent a lot of time in GCP, it seemed like it was harder to understand GCP itself as a platform compared to AWS.
That is to say that Google APIs and services seem fine, but figuring out project management and infrastructure management feel incredibly weird. Not necessarily bad, but arcane and awkward where in AWS I can just hit the ground running.
Arguably, debatably, GCP might have the "more correct" model with resources scoped to projects and such, but it does make the learning curve harder.
> figuring out project management and infrastructure management feel incredibly weird
It's not just you, and the situation is worse than if they had no configuration management offering because, as Google is wont to do, they have several of them in various states of disrepair
- they cite terraform as their go-to deployment solution in damn near every blog post, but if you're trying to create something for (new users | deployment into _someone else's project_) the instructions start with "well, open a Terminal and ..."
- they now have some kind of "hosted terraform runner + state" whose name escapes me but is hiding somewhere in this list of a bazillion similarly named Cloud Somethings https://cloud.google.com/products?hl=en#section-14 ("Infrastructure Manager" is the one I was trying to think of https://news.ycombinator.com/item?id=37548639 and is, ha ha, not on that products page which is why I could not find it)
And speaking of, there is, of course, no way to enable project services via Deployment Manager, so pound sand if your Project was not already carefully configured in advance of Deployment Manager
To me, GCP does seem easier to use, but I've recently had some instances where I had externally-hosted services (Zaps) make calls to my cloud functions there and inexplicably fail, with no logs whatsoever. While I was trying to figure out what went wrong, I found some other people online who said that their Google rep had mentioned "service instability" or something of the sort to them. Thinking that must've been the case, I went to reach out to GCP support (as nothing was mentioned on their outages page), only to find that it costs $30 / month to get help with anything other than issues with billing (and their pricing page threatens to ban you from support access entirely if you are caught buying it and canceling it after use).
Does anyone have recent experience with both? I'm in the market, for a startup, and I need to decide. My priorities are the data warehouse (BigQuery vs. Redshift) and ML (Vertex AI vs. SageMaker).
This article is three years old. Vertex did not even exist then.
Don't know enough about Vertex AI, SageMaker is great though. But on BigQuery v Redshift: Having used both over many years, BigQuery is the clear winner. It's a much better, much more modern product.
BigQuery is also a central part of GCP, with almost all services having integrations to it (PubSub, CloudSQL, Bigtable, etc). It also seems to get a lot of resources and is continuously improved. That is not the case for Redshift, which is not as important to AWS.
Choose whoever gives you the biggest startup credits. The UX and UI experience is secondary to that imo, and the other technical differences aren't something you will care about as a smaller startup.
I would choose Redshift over BigQuery but that's because I know how to use it. Actual skill at databases is increasingly rare, so BigQuery wins this one for most. Watch your bill.
One of the 2 never deprecate anything and ensure your workload will run untouched for 10y or more.
The other one will force you every 6 months to update sdk, api endpoints or even kill a service you need in weeks.
I let you guess who's who
As much as I don’t like using a Google product, I have to admit GCP is wonderful. I really think GCP is the best UX Google has to offer. My favorite feature is that whatever you do on the web console, GCP will show you the equivalent gcloud CLI command. It can also give you the Terraform plan for some already created resources (maybe it’s even everywhere? Not sure)
The configuration and naming of the services is also wayyy more sane than AWS overall, you actually know what they do from the name only most of the time.
I personally enjoy GCP much more because it's easier. You can do almost everything from the UI and products are named the way you expect them to be named (except for a few exceptions).
When you are doing devops on the side not as your main job, it's really a game changer compared to the cryptic AWS UI.
The only part lacking imo is the log/monitoring which is definitely subpar, just logging proper json is a mess.
I mean, the author makes the arbitrary decision to equate AWS accounts with GCP projects, and then from there determines that this is unsatisfactory. This is not my experience at all, and it wasn't until I joined a Fortune 500 company that I ever came across the idea of separate accounts - and they were split along corporate accounting divisions.
GCP has much better UI than AWS. GCP is easy and fun to use, while AWS looks like fighting 90s Windows 3.11 app
(No comments on the poor behaviour towrds customers by both and Azure as well)
Edit: And after fully reading the article, I agree with the author. Yes, GCP is very easy to use compared to the monster AWS is. Its Googles poor reputation, esp amongst the HN types, that I suspect is the reason not many people use it
> GCP has done well integrating their different services together. GCP provides a smaller set of core primitives that are global and work well for lots of use cases. Pub/Sub is probably the best example I have for this. GCP has Pub/Sub. Pub/Sub seems flexible enough to replace most (all?) of AWS’ various queues.
I feel like if you're going to spend this much time writing something in this much detail, the least you can do is try to understand some of the things you're criticizing and not say things so wildly incorrect.
> In AWS you have SQS, SNS, Amazon MQ, Kinesis Data Streams, Kinesis Data Firehose, DynamoDB Streams, and maybe another queueing service by the time you read this post.
The most accurate criticism would be that Pub/Sub combines AWS's SQS and SNS. AWS had SQS first for 1-to-1 async queuing integrations. Then they added SNS for fan-out. GCP just started with fan-out from the start and said "well if you don't want to fan out, and just have one subscription, it's basically fine.
That's actually also true with AWS too - nobody is stopping you from using SNS this way. SQS was the first AWS service (S3 went "GA" first, though), and AWS doesn't deprecate things that are popular with customers.
Amazon MQ is Amazon's managed Apache MQ. You can criticize Amazon for hosting managed open source software, but there is a reason why it exists for customers that want to use an industry standard queueing service but not worry about operating it.
GCP's competitor to Kinesis isn't Pub/Sub, it's Dataflow -> https://cloud.google.com/dataflow Both are described as for the same use case - streaming, analytics, batch processing.
Kinesis Data Firehose may be another valid criticism. It can be thought of a "Simplified Kinesis that can push data instead of pulling it". It is clearly coupled tightly with Kinesis Data Streams itself, so in another company that cared less about not breaking backwards compatibility maybe they would've bolted those features on top of Kinesis.
GCP lost me when I had to enable API errors from the console in order to see actual error in the console rather than a user hostile “Something went wrong” type message.
There is probably a rational reason for this behavior, but I don’t care. Just tell me the error.
I'll continue beating the dead horse: I don't trust Google.
At best GCP is slightly better than AWS (debatable), which is not enough to offset the risk because of how much of a pain it is to switch cloud providers.
Even if GCP shutting down is one in a million, aws shutting down is 1 in ten million.
Also, I keep getting the feeling that Google keeps trying to automate their customer service through bots. I have use quite a few google services from youtube, to google workspaces (a paid service) - I have never talked to a Google representative. I have talked to AWS service reps multiple times, I have talked to Amazon reps multiple times. Amazon as a company has real people you can talk to.
I don't trust google to not shut down my gcp account because my gmail was connected to some project where I accidentally sent a bunch of spam emails to a test account. And if that did I happen, I feel like I would just get an automated message and a bunch of hoops to jump through before I could talk to a real person.
> The group [Pichai, Page, and Porat] even talked about—and eventually dismissed—the idea of leaving the market entirely, this person said. [1]
That they’ve actually discussed shutting it down in the recent past lends plausibility to this risk. In 2019, they set 2023 as a deadline for moving into the #2 spot ahead of Azure. Obviously, they’ve not gotten anywhere near that.
Wow. Imagine top level execs at Ford discussing, but eventually dismissing--the idea of leaving the automobile market entirely. Their hearts really aren't in it as much as with AWS.
Google is an advertising company. They're planning an exit in a non-core market. It shouldn't be a surprise. The weight of "traditional google" has held zero value to me in measuring their cloud product.
Google's cloud products are built around the needs of advertisers. A large and slow backend that's meant to churn ungodly amounts of data.
Amazon is a retail company their cloud products are build around this need. They have a highly segmented and mostly nimble backend that's mean to build unwieldy amounts of API.
Ford, ironically, is an example of a company that has recently exited a huge business segment - they no longer make sedans. They now exclusively make SUVs and trucks. It is largely thought of as a pretty good move on their part.
Google probably should spin off GCP rather than killing it, but it's not a terrible idea to divest from a failing arm of a business. Google (like Intel) just does it too early.
This is a US/NA focused comment. Ford makes sedans in EU and other markets. They also make sedans for the US market in China and other manufacturing locations.
So it's true that Ford US manufacturing have exited sedan production, Ford itself continues to build and sell sedans.
I think this is an unfortunate conflation of free Gmail/etc. consumer products with GCP.
All of what you say is pretty accurate for free-tier Gmail/etc. No customer service, risk of an account getting blocked and nothing you can do, new apps not finding success and getting cancelled.
But none of it is the case with GCP. Customer service is great and you can reach real people easily, paid accounts aren't getting shut down without recourse unless you really are being abusive, and Google's not cancelling the services companies are paying for. (The same goes for the paid tier of Google Workspace.) It's a normal paid B2B relationship with all that usually entails.
It's unfortunate that people take their experiences and the stories they hear about the free consumer side, and extrapolate them to assume they're also true about the paid business side. It's understandable, but it's just not the case.
And neither GCP nor AWS is getting shut down. Even using the numbers you give, the answer is that the risk of either shutting down is zero for all intents and purposes. There's no reason to split hairs over which of two infinitesimally unlikely events is more likely, or use that as a justification for choosing one or the other.
> conflation of free Gmail/etc. consumer products with GCP.
* Google Domains
* Google Cloud IoT Core
* Jamboard
Also they increased Google Maps pricing by like 10x at one point, and they increased Cloud Storage prices pretty substantially last year too. Price increases can be just as impactful as killing a product. I don't think AWS has ever increased any prices or shut down any service (though quite a few are essentially zombies - SimpleDB, OpsWorks).
Then on the consumer side, Google have killed quite a few paid products. One that bit me was they shut down Google Cloud Print which killed the ability for me to print to my (cheap) printer from my phone. Besides that, there was Nest Secure, Stadia, etc. etc.
Google's reputation problem isn't just coming from their free consumer apps.
AWS just KILLED EC2!!! Well, EC2-classic. And they did so with two years of notice and support to transition all customers. Really a class act of migration. I'm not sure Google won't just send out an email on a Friday before a long weekend and then kill the servers the following Monday.
That one was such a long time ago when they were struggling to find PMF. I do my best to avoid Google bc I don’t trust them or their quality, but I think I’d give them a pass on the search appliance.
> I think this is an unfortunate conflation of free Gmail/etc.
I would also say that this is a byproduct of how google treats its customers, even on paid platforms. I used to manage Google Workspace few years ago (2016 -> 2020) and GCP (2018-2019) and I remember the difficulty I faced when attempting to reach a human. Even if I were to able to reach someone, I got someone who clearly was a tier 1 support, who wanted me to troubleshoot things by "turnings things off and back on again".
I've also seen blog posts (some even on hacker news) mirroring my experiences, so I know it's not just a "me thing".
But I am not a Google customer. I am a Google user. I use all sorts of Google properties, but i dont give them any money.
What most Gmail users call "customer support" is really "user support". Your free account has the durability of what you pay - zero.
So should we judge customer support based on user support? Technically no. Do we? Of course we do. We absolutely judge the unseen experience on other things we can see.
Quite literally, we judge a book by its cover.
Google has a reputation for bad support. It has earned this reputation from endless free users. It may not be fair, it may not be true, but it exists.
Equally it has a reputation for shutting down services. Popular services. Gmail is likely safe. GCP is likely safe. Am I gonna bet my business existence on "likely"?
Getting rid of https://domains.google is a good indication that nothing is off-limits and everything is a bean counter report away from being abandoned.
What's worse is that their loss-leading free products kill competing products before they finally abandon it themselves, leaving the space much worse than if they had ever entered it.
This really resonates with me – yeah, the supposed API-driven engineering company, makes it no longer possible to automatically provision domain names for its "valuable" cloud computing customers?
What possible end could that serve? I am baffled by the idea that succeeding via open access to their infrastructure is not a serious long-term goal for Google.
For a company who ostensibly is existentially interested in developing at least one meaningful complement to it advertising business, of all the things https://killedbygoogle.com/ over the years, why the domain registrar? The cost to developer trust vs. the cost of ongoing operations – did they not even have that conversation?
Now I imagine how I would've felt to have my registration transferred to – I can't even recall who bought their customers – and I try to imagine putting faith in trusting GCP products with a startup idea, where ostensibly their second-mover advantage could let me move faster in greenfield development ... and I throw my hands up. This is a company acting like it places no value on goodwill, not even from a bare bean counter perspective.
I guess I'll stick to AWS (and more bespoke cloud offerings).
> I think this is an unfortunate conflation of free Gmail/etc. consumer products with GCP.
Parent did point to Workspace where they also didn't get customer service.
To lay it first: GCP has excelent support if you're in the right bucket. For instance startup support programs will have dedicated engineers, sometimes on site, ready to meet and answer questions.
You'll also get that at the higher tiers (around where you start to negociate rebates in echange for usage volumes) with recurring slots with a support engineer to discuss your issues and growth inside the services.
But outside of the blessed situations, if you're just a mere paying user/business there will probably close to nothing for you.
And yes, education/corporate targeted products also get killed. Last month Jamboard's name was etched into its tombstone, along with Google Domains and so many others.
Even within GCP many products will get merged with more or less changes to adapt to. Stardriver becoming a different service with an unsearchable name comes to mind. Or the GA4 transition with the breaking changes.
I remember losing an argument with my company (that I cofounded) about using Google's awesome recruiting app that was part of GSuite. I said I don't trust Google not to kill it if there are less than a billion users on it. Everyone, and I mean everyone else said, nah. They'd be crazy to kill it. It's part of GSuite. They offer that to businesses and it's too core of a suite for them to kill it.
THAT was the name, ty. Google Hire. Yes, it was an excellent product. Leadership at the top needs to understand the cost in reputation and change the culture. Large corps aren't good at changing culture.
We had our main GCP account suspended because we were running a Lightning node, and some Google automata flagged us as mining.
We couldn’t get hold of any actual person at Google, and were told by our Google reseller to buy a fairly expensive support package to have our issue expedited after raising multiple appeals/objections. Suffice it to say, we run out of AWS now. I’ve heard GCP support (in terms of reaching an actual human support person/engineer has only gotten worse since then, and our experience occurred a good few years back).
This is kind of a problem with non-paid support I think. I had an AWS account with some credits that were going to expire and decided to use them to spin up a bare metal instance. My account was immediately flagged and I got locked out. I finally managed to reach someone who made me jump through hoops changing my password and rotating my API keys. It still took a few days before I was able to log in again, and by then my credits were expired. Luckily I wasn't doing anything important in my account, but someone running a business would have been screwed.
> none of it is the case with GCP. Customer service is great and you can reach real people easily
I'm curious how recent your experience was with GCP support? Sadly several contacts of mine were not long ago laid off from working there. Many of them had 10+ years industry experience. Presumably their roles were off-shored but from my experiences with other companies who have off-shored technical support, I don't imagine you'd get the same customer experience as you did before.
I worked at an ad agency for a time. We were spending millions a year with Google on AdWords.
We onboarded a new client who had many different locations serving different brands. We set up these accounts, set up Google accounts for the locations to own/access the AdWords accounts, etc.
Out of about a dozen accounts, one got suspended.
There is no general Google Support for that. So I contacted AdWords support. They put in a ticket for me with the accounts team. They also told me it's unlikely I'd ever hear back about it and advised me that my best course of action was just to register a new account and hope that wasn't suspended too.
Three years later when I left that company, I was still getting occasional emails to remind me that my ticket was still open but there were no updates to provide.
Meanwhile, in AWS land...
With my personal AWS account (~$3k/yr spend) I've never had an issue getting in touch with support that can resolve any issue I raise. I accidentally bought a bunch of reservations under the wrong account and put a ticket in and they swapped them to the intended account right away. I raised a ticket about trying to use a new product and running into some issues that appeared to be on their end and a day later got an email from the lead engineer for the product.
At a company spending ~$250k/yr, not only could I access _the exact same support_, but we also had an account rep that would swing by the office once a month just to check in. We had his direct email and phone. He was actually empowered to do things. We had an AWS key leak and ran up over $100k in additional costs before we caught it and our payment didn't go through. Sent him an email and almost immediately got back to not worry about it--he'd put a note on the account that no action was to be taken without his approval. Shot off a ticket to support about the spend due to a security breach, and they asked us some basic questions to demonstrate that we knew how to prevent this happening again and then cancelled over $100k in charges. (Current company I'm at spends ~$360k/yr on GCP and we have no contact at Google.)
This isn't "conflating google's free product support with their B2B support". This is "google's culture does not leave room for providing proper product support".
That doesn't put my mind at ease. Under who's definition? Do I even get told what I did wrong? You try to draw a distinction between the free and paid products but that doesn't address the perception people have of the company in general. If I was a small startup I wouldn't want to risk it.
I remember hearing a story about how one engineer had worked for something nefarious (spam? gambling? straight-up malware?) and got hired by a different company. Eventually something triggered on that engineer's account that caused Google to spread a blacklist to everyone's account at the new company.
Potentially apocryphal, but it rings true enough that you have no idea what might anger the Google automation.
It's not just "free" customer products. See: Pixel Pass being canceled right before it was supposed to pay off with a phone upgrade. Those people paid significant amounts of money.
I don't think GCP is going to shut down as a whole, but that doesn't mean I'd trust Google to keep any specific service I might depend on up and running.
> See: Pixel Pass being canceled right before it was supposed to pay off with a phone upgrade
Did you first try to understand what Pixel Pass was? No, it wasn't supposed to "pay off" with a phone upgrade. To get a new phone, users would have had to renew their Pixel Pass subscription. It wasn't - pay monthly for 2 years and get 2 phones: one at the start and end of the 2 years.
The basic thrust of your argument is equivalent to "Google shut down a product we were paying for at the end of a normal billing cycle, so how could you be mad?" Fair enough, but acknowledging Google will honor basic contractual requirements before shutting a service down doesn't really mitigate the argument that "Google might unceremoniously kill a paid product with minimal warning." Props to Google for not committing actual fraud, for whatever that's worth.
Having spent the past week dealing with GCP support, which I pay for, I can assure you, it sucks. It’s miserable and my least favorite part of GCP by far.
I used to share that sentiment about GCP until they shut down a service I was using (Cloud IoT). Now I try to avoid GCP even though I really do like a lot of their products more than AWS.
> And neither GCP nor AWS is getting shut down. Even using the numbers you give, the answer is that the risk of either shutting down is zero for all intents and purposes. There's no reason to split hairs over which of two infinitesimally unlikely events is more likely.
That's what I thought for a long time about google domains. Yet here we are.
Ugh. So it was first reported that Google Domains was being abandoned, but Google Cloud Domains was still just fine. I thought -- exactly, you can count on their paid enterprise cloud services.
I looked it up now to reconfirm, and it turns out a few days later it came out that Google Cloud Domains was also being shut down? [1]
WTF. OK, well that's idiotic. Maybe I have to take back my parent comment then. That's one of the dumbest corporate own-goals I've ever heard of.
That's not something I can even begin to explain or understand at all.
Google Domains is not being shut down - it's being sold to Squarespace. I would assume Cloud Domains either went with that package, or is being removed as part of the deal.
Selling to another company != shut down in my book. Although I'm already in the process of moving domains to another registrar...
Google, and all other domain registrars, are obliged by ICANN to allow domain migrations in case that the original registrar is shutting down. Getting money from Squarespace is just icing on the cake. You're sounding that this is a decision that Google is doing voluntarily, but it's literally not an option here (for once).
Also if they're still keeping the original Google system then it's believable that they are indeed just selling Google Domains, but the fact that all domains must be migrated into Squarespace's system tells a different story.
They are forced to sell it by their contracts with ICANN - this is not a decision that they have done voluntarily. If they can legally shut down Domains they would have done it.
Sure, in any other contexts, selling Stadia customers to Microsoft or Nvidia (for example) would be a voluntary decision, however they are barred from just shutting down this one. They can even shut down Gmail or YouTube with no legal repercussions (sure their reputation will suffer but legally it's in the clear), but Domains is in a different legal standing.
While chump change to the likes of Google, it demonstrates Squarespace views this business as highly profitable. Migrating an acquired business into your systems makes a lot of sense.
Unless you have some evidence it would have been just simply shut down otherwise, I think you're inferring things that do not exist. Few if any of the other "shut down by google" operations could have sold for anywhere near this amount, as they almost universally lost money and/or were niche.
And they're also shutt- I mean deprecated their enterprise version? (https://cloud.google.com/domains/docs/deprecations/feature-d...) That doesn't sound like "oh, we're selling this because it's valuable money" but more of "we don't have the energy to maintain this".
First, selling it to another company is just shutting it down but doing you the courtesy of migrating the data to another vendor. It still results in all of the management UIs, integrations, and APIs that you rely on going offline. It just avoids creating an immediate outage (but it will create one eventually, unless you start interacting with this other vendor).
Second, the point has repeatedly been made that GCP is fundamentally different from Google's other offerings and essentially immune from being shut down (even in the responses to this article). That may be true for GCP as a whole, but this proves that it's not true of the individual sub-components of GCP, even ones that seem extremely core.
I actually agree with the article that GCP is just good in ways that competitors aren't but... Running on their platform does continue to be a bit nerve-wracking.
As pointed out multiple times previously, Amazon and Microsoft provide domain registration services even if it's a solved problem. It's not that Google needs to be the best domain registration platform, but providing a normal domain registration service is miles better than not providing one at all (for example simplified billing and administration for smaller businesses, and automation for bigger ones).
Google, and all other domain registrars, are obliged by ICANN to allow domain migrations in case that the original registrar is shutting down. Getting money from Squarespace is just icing on the cake.
Google is selling Domains to Squarespace. Yes, many techies will migrate their domains, but majority of the people on Google Domains probably wont. That's why Squarespace thought it was worth paying anything for, after all.
Personally, I'm moving my domains already. But, saying Google Domains was shut down is inaccurate - it was sold, as business units/subsidiaries tend to be...
They are forced to sell it by their contracts with ICANN - this is not a decision that they have done voluntarily. If they can legally shut down Domains they would have done it.
Sure, in any other contexts, selling Stadia customers to Microsoft or Nvidia (for example) would be a voluntary decision, however they are barred from just shutting down this one. They can even shut down Gmail or YouTube with no legal repercussions (sure their reputation will suffer but legally it's in the clear), but Domains is in a different legal standing.
I’m not seeing why you’re being down voted. Indeed, the point being made (that Google would simply aborted all their domains if it weren’t for ICANN) is strange.
Of course they’re likely to not outright get rid of them thanks to ICANN. They could have however just given them away rather than selling them off. I feel like there’s some precedent there too? Maybe from Wordpress?
In any case, they weren’t forced to sell them. They had other options including _not_ shutting down. But even if they did merely give them to another company or sell them, people would have the chance to move their domain to another provider.
Really I just don’t get what point is trying to be made. Google shut down domains in every good faith interpretation of the phrase “shut down”. All the ICANN argument does is try to conflate “shut down” with “going against ICANN rules” but no one was ever suggesting that.
> In any case, they weren’t forced to sell them. They had other options including _not_ shutting down.
Fine, sure, but this is a cop-out. Clearly they really want to clear the thing: if it was to be a GCP-only option with no more consumer-focused Domains, they have temporarily set a transition period with no renewals and new domains and then bow out of consumer space, but even the enterprise version is being shu- sorry, I'll be using Google's term here, deprecated (https://cloud.google.com/domains/docs/deprecations/feature-d...). The Squarespace buyout is irrelevant here because unlike GCP Domains there are no automation features in the Squarespace's system (and have no plans to implement one), so you are required to migrate to another provider like DNSimple or AWS. This is a clear sign that they really want to dispose of it as soon as feasible.
> Really I just don’t get what point is trying to be made. Google shut down domains in every good faith interpretation of the phrase “shut down”. All the ICANN argument does is try to conflate “shut down” with “going against ICANN rules” but no one was ever suggesting that.
It's a reasonable assumption when you're talking about their first time in closing down things, but there is a clear trend, even solely in the enterprise space. (https://news.ycombinator.com/item?id=38020254) At this point, it is clear that Google does shut down things when they feel it.
Really? I've got associates at less than that (10-20k/mo) that have access to real people. One associate just crossed the $1k/mo mark and their human contact-ability improved. My GCP spend is <$500/mo - I don't get shit.
I had a Google Workspace account and a bizarre issue with my account thinking I was on a Caribbean island. I was a paying customer, and could talk to a human, but it was an awful experience.
>All of what you say is pretty accurate for free-tier Gmail/etc. No customer service, risk of an account getting blocked and nothing you can do, new apps not finding success and getting cancelled.
Dunno, they've still taken the time to implement all this crazy auto-management software for their free tier, so I'm fairly confident they'll deploy it from time to time on their paid stuff.
I did mostly agree with you that GCP is not Google etc etc until a couple weeks ago when they suddenly announced that they will move most of Policy Intelligence under Security Command Center Premium, throwing most of their customers security teams under the bus.
GCP starter earning a bad reputation for reliability, transparency, and support on day one. Maybe that's changed? I feel like a see a "GCK is hosed, google support is AWOL, our production environment has been down for 48 hours with no ETA" post on HN once a year.
Again, I'm willing to be wrong about recent reality, but GCP does not have a good reputation with its customers.
I work for a fortune 100 company. Years ago we looked at all the cloud providers trying to determine who to go with. Google was thrown out on the first day for this very reason. They simply cannot be trusted not to kill their products at the drop of a hat.
I was expecting rigorous analysis in terms of cost of services and the complexity/simplicity of offering, reliability figures, etc. but this fortune 100 company went with feelings
It seems like all the OP is saying is that the company evaluated alternatives (Azure & AWS) whose cloud products are "first class" citizens of the business whereas with Google the first class product is search, advertising, Android (a couple other things but you get the idea).
It doesn't seem too far out of left field that Google would flounder with all it's cloud products being phased out in favor of some other new product they've made or acquired.
Yeah we’ve had one too. Actually no two. Wait three. Actually I’ve lost count. In the 6 years I’ve been using GCP we’ve had a new rep practically every quarter. It’s ridiculous.
AWS is stable. In that, the DX is predictable. I'm using AWS for over a decade and had huge gaps in between but coming back never was shocked or surprised by things totally reshuffled.
On GCP, not the same. The GCP console of around 2012 if memory serves me well, is barely recognizable. That just the UX and I'm sure APIs would have changed as well in the meantime.
The hip product management culture of Google is beyond me. Today's cloud console would be something else tomorrow and I'm sure some hip and smart PM is chalking that out on their Chromebook or something. Sorry for the stereotyping.
As of speaking to customers, I bet AWS (real people) directly, routinely reach out to even 2 person startups. I have experienced it myself. They really do care. Even I had multiple hour long calls with Azure representative for an account who's monthly spend was a joke.
On the other hand, good luck with getting anyone from Google on email let alone phone.
I concur. Google doesn't seem to believe in a tangible customer service methodology at all. They go out of their way to remove human interaction at seemingly every level. I don't know if it's a legal strategy or what, but it gives me bad vibes too.
GCP has people you can talk to, you just need to bring enough money to the table for them to bother. In other words, the fat cats get support, the rest can suck it.
A good part of GCP is part of Core google infrastructure.
Spanner is used ubiquitously inside of Google, supporting services such as; Ads, Gmail and Photos. ... Spanner on the other hand processes 3 billion queries per second at peak, which is more than 20x higher [than DynamoDB], and has more than 12 exabytes of data under management.
https://cloud.google.com/blog/products/databases/announcing-...
Monarch: Google's Planet-Scale In-Memory Time Series Database, provides metrics for Google's own services and GCP Operation suite.
https://research.google/pubs/pub50652/
Zanzibar: Google’s Consistent, Global Authorization System - underpins access control across Google's product and GCP IAM.
https://research.google/pubs/pub48190/
I would put the odds quite a lot closer to 1 in 5 than 1 in a million. Google exec shuts down lackluster business ? It would not even be news outside tech/business circles.
it does seem like any of Google's support options for paid services have the primary goal of reducing support load on Google, not to solve problems for paying customers
No interest on engaging on the core issues of trust, except to say my standard bit: HN is a site predicated on the whole idea of embracing risk. Except with this one particular vendor who everyone loves to distrust. Maybe... it's not about risk at all?
This is a deeply weird take IMO. Nobody "embraces risk" because they have a risk fetish. You take on risk because you believe you can be paid for it, and perhaps you are better equipped to mitigate the risk than the people paying you to take it.
There is no payoff for using a Google product versus one of the competitors, so a rational person would not accept the risk that Google pulls the plug on a product, or some contractor gets banned by Google and gets your whole account frozen, etc. There's no upside. It's not even gambling because there's no "win" possible - it's more like shooting an arrow straight up into the air and hoping it doesn't land on your head.
> There is no payoff for using a Google product versus one of the competitors
The linked article is literally about how Google is better than its competitor though! Obviously some people disagree.
If you want to write a nuanced take about risk and benefit, I'm there for it[1]. It's the stunningly absolutist take on something as clearly-not-a-big-deal as a cloud service provider, by people who would otherwise be willing to bet their careers on a job with a good vibe, that seems "deeply weird" to me.
[1] Actually I'm not. That's stuff's boring. But I respect that people do it.
There’s a stark difference between risk that is predicated on your own wits and risk that is mediated entirely through a capricious and aloof supplier with a bit of a reputation for the rug-pull.
Nonetheless the chances of a median HN poster's employer being shived by a rogue Angel or dying to a founder feud are vastly (like, vastly vastly) higher than having Google drop one of their dependencies. And I guess I'd expect the discourse to reflect that. But instead it's the boring tech giant (yes, also my employer, though I work nowhere near cloud) who everyone seems to think is the existential threat? Like I said, I don't think this is about risk at all.
GCP, AWS and Azure are all, for sure, 100%, big revenue centers for their corporate overlords. Cloud is where you go to make money, not lose it. It's the "enterprise" of the modern world. The only problem with it from a business perspective is that it's increasingly commoditized and so everyone can only compete on price these days. So margins will trend to zero over the decades, but these will always be profitable.
All of the smack talk about AWS rings true in my experience. The documentation is terrible and incomplete.
That said… there's one MASSIVE reason I trust AWS over GCP.
Google has a knack for killing products/services. Even when they seem to be popular. You don't know if a service will exist next week. But you took the time to invest in the ecosystem and get to know the offering…
But Google does what Google does, and off to the pile it goes.
Has Google killed Cloud services people relied on? I am asking in good faith as I don't know.
Whether Google kills random small-traction consumer products is kind of orthogonal to the Cloud question. If Amazon retail discontinues some Amazon Basics product, we don't read into that for AWS.
a.k.a. Freedom of thought. Warning: extremely large wall of text waiting for you.
On a more serious note: I, and most of the business I work for, value stability over hype. Skip to the almost last paragraph "Fear that GCP may be abandoned by Google", if that is of interest to you :)
this is a rather inaccurate description of the article
not a wall of text, the abandoned part is in the middle, not the end
GCP has more uptime than AWS, and is stable, not sure what you are insinuating with "value stability over hype", the businesses I work with leave AWS for GCP for (1) cost savings (2) developer experience
it hits many of my points for choosing GCP over AWS
Ah, the time has come for me to do another rant about Amazon
- Open amazon app on your phone
- Type in “craftsman firepit spark screen” into search and get results
- Is the top result a craftsman product? No. Why? Who knows. But it’s ok, it’s like the third one down, though this is already hinting on the things to come.
- Open up product details for the Craftsman one. It’s called, and make a mental note here “CRAFTSMAN 19.5 Spark Screen for Smokeless Fire Pit Stainless Steel Mesh Lid Outdoor Fire Safety for Backyard Bonfires“.
- Oh no, it’s not quite the right size for the model I have. But there’s a helpful link to “Visit the Craftsman Store” at the top, which is I suppose a little section of Amazon that is all things Craftsman. Let’s click it to find the right size model.
- It takes me to a page with a nice big Craftsman Logo and a search bar inviting me “Search all Craftsman”.
- I enter “spark screen”. That’s the name of the product from the listing after all.
- I get 5 results. They are: screwdriver socket, 46 inch lawnmower blades, screwdriver set, pressure washer, and an electric lawnmover.
- The end.
This is the company on the forefront of machine learning.
PS: As a bonus story - I was recently trying to find “Wonderpets” cartoon for my daughter, using Amazon Prime Video apple tv app - and not quite remembering the name, I typed in “wonder pets” into the search box, and as you might have guessed, the cartoon I was searching for wasn’t in the results.
Makes you wonder how many more resources of time, money and people does Amazon need so that my simple interactions with their consumer products are not such a subpar experience.
A few years ago I worked at a company that lacked any form of CI/DF.
I set up TeamCity in a few hours and it was up and running, but
it did not see much adoption.
Then they had a super long internal project on how to improve
their development processes.
The code base was more than 90% .Net code on the back end.
The company decided they wanted to avoid vendor lock and
thus, they would not use Azure, and decided that AWS was the
best candidate.
My team was assigned to configure and set up the CI/CD pipeline.
After quite a lot of time, months, we had to admit that we
had failed.
The company hired an AWS expert who didn't get much done.
That person was soon gone.
At least a quarter has passed since it began.
The company hired 2 "elite", "top of the line" AWS experts.
They got it done, but it took them well over a month.
Afterwards it mostly worked.
I dont want to know the total cost but it was enormous.
Since they were a Microsoft shop, going with Azure would
have saved them a s*load of money, as well as time.
Since Azure integrates pretty with Visual Studio configurations
and solutions we would have it done in less than a month without
external help.
I set it up at a different shop and I spent a lot less than a month.
I can't make a judgement that Azure is technically better,
perhaps when it gets up and running it is a superior
solution, but for a .Net shop I would choose Azure again
the next time around.
There's a decent chance that in a few years GCP will be no more.
I had an argument with one of the biggest investors in Google a few years ago, in which I was predicting exactly this scenario. He didn't believe me.
Perhaps I was right after all.
GCP lost a ton of money since its inception. Its leadership is so far away from being able to run this business properly, that I would never recommend anyone to put all their eggs on GCP.
Plus, as your company scales, you should REDUCE, not increase, your cloud usage, in favor of a properly optimized on-prem.
Wait, so a few years ago you predicted that they'd deprecate cloud, and now, when GCP is making a profit and growing revenue substantially, you're more inclined to think your prediction is coming true?
>Plus, as your company scales, you should REDUCE, not increase, your cloud usage, in favor of a properly optimized on-prem.
Yes if you get to dropbox size it might make sense to go to on prem, but most F500 companies save money going to the cloud for a multitude of reasons.
> you should REDUCE, not increase, your cloud usage, in favor of a properly optimized on-prem.
Based on this. Not much. Unless all you need is a single location and a couple of load balancer servers. No you should not move to on-Prem. It has no benefit and isn’t magically cheaper.
- Cloud Run. Best way to deploy containers hands down. All of the benefits of a serverless/containerized workload with all the ease of a traditional VPS deployment. Extremely cheap (pay $0 for side projects with little traffic).
- BigQuery. Very easy to use with immense power without having to deal with the details yourself. Billing can be either extremely cheap or rather expensive depending on what you're doing, though.
- GCS Archive Storage. 1/3 the cost of glacier for storage ($0.0012/GB/Month lol), but more for retrieval. Has none of the annoyances of Glacier (you can download your files instantly, upload using normal APIs). Perfect for extremely cheap backups.
- Cloud Spanner. I've not had a reason to use this yet myself, but there really aren't any comparable offerings that I know of.