I think GCP is better than AWS (2020)
nandovillalba.medium.com
nandovillalba.medium.com
- 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.
Speaking more generally, it seems AWS is allergic to creating products that scale to zero nowadays.
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.
I am a small fish in the big sea but I use this for my personal projects:
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.
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.
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.
https://status.cloud.google.com/incidents/fmEL9i2fArADKawkZA...
"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."
(This hit us hard.)
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.
Apparently some of the key people behind BQ are now working on MotherDuck, which is a cloud data warehouse version of DuckDB.
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.
Do both of these guarantee that if a single data center location catches fire, your backups will not be lost?
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.
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.
you can set --no-cpu-throttling which keeps the cpu allocated even if the request lifetime is over. Used it for Background tasks
That is interesting. How to you access this API? Can you do SFTP?
This has about the same pricing:
https://www.opendrive.com/pricing
(Yes, it says unlimited, but they told me, they significantly slow it down after 10 TB)
AWS S3 and GCP GCS are basically the same in my head.
Where things fall apart are actually the cost estimator. GCP’s is far simpler. AWS’s makes me wish I had Corey Quinn on speed dial.
Redshift is far too complicated and has too many knobs. Give me BigQuery all day long even with its quirks.
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.
Confidence that it will continue to exist in the next 3-10 years?
Fun read:
https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
Name the odds and condition you think gcp will violate.
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.
0: https://abc.xyz/assets/d4/4f/a48b94d548d0b2fdc029a95e8c63/20...
People keep saying things will be shut down and I think they should put their money where their mouth is.
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 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.
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".
Are you interested in making a bet on the chance GCP will be discontinued?
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 is the time for the contracts to settle between these enterprises and cloud-vendors.
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.
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.
Whether or not they'll continue to lose billions a year for Google I can't say.
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.
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.
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.
Amazon supports most stuff roughly forever.
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.
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
- [1] (https://firebase.google.com/docs/dynamic-links)
- [2] (https://www.reddit.com/r/Firebase/comments/14cj7au/firebase_...)
We are talking about the Cloud.
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.
Google has demonstrated a culture of killing off services. https://www.thestack.technology/google-cloud-iot-core-retire...
Amazon, on the consumer side has many canceled products. On the AWS side they have demonstrated a commitment to keeping old services alive.
So on a surface level, your analysis holds up. But where Amazon has earned some goodwill by supporting even barely used services, Google has not.
Perhaps they will given time, as GCP is fairly new. But when you are talking tens of millions of dollars in spend, reputation matters.
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.
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.
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.
You can share resources across AWS accounts. I don't know for easy that is on gcp, but it didn't seem crazy on Amazon.
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.
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
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.
Google on Stadia:
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."
https://www.theverge.com/2022/9/30/23378757/google-stadia-co...
Bonus comment from Google regarding Inbox:
"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."
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.
> 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.
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.
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.
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?
That's the TAM.
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.
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.
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.
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.
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.
No thanks.
https://www.sec.gov/Archives/edgar/data/1652044/000165204423...
Look at page 12.
The whole reason why Google cannot be trusted here is precisely because of their tendency to be inauthentic in their public statements.
And then they'll turn it off as casually as you or I might turn off a garden tap.
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.
Most people and companies don't do things which aren't in their interest after stating they will. It isn't a Google thing.
Company culture can help predict what interpretation a company will pick.
Google's culture is much more trigger-happy about interpreting killing off a service as being in the company's best interest than Amazon is.
AppEngine is going on, checks notes, 15 years now.
Since you're checking notes, please check out all the AE service deprecation notes.
Disclosure: I worked for Google for ~10 years, and I fought internally many of those deprecation decisions. I did not succeed.
I see that as a good thing, it means they are still working on it.
My guess is not, or you would have a different opinion. But that's just a guess
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.
Now give me back my downvote please.
You also just said that you used it very effectively back when it was a different thing.
I think we agree in many more ways than we disagree.
"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.
- In 2012 App Engine deprecated the "Conversion API".
- They notified this deprecation in August 2012, and they told users it would stop working only 3 months afterwards.
- You were affected by this deprecation.
- You created an alternative to it, that worked on Heroku.
Source: https://groups.google.com/g/google-appengine/c/-JJccGx5RRk/m...
Did I get this right?
You are awesome. We are just choosing to remember the past with different colored glasses.
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?
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.
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.
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.
GCP support also provides the answers I need.
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.
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.
- [1] (https://firebase.google.com/docs/dynamic-links)
- [2] (https://www.reddit.com/r/Firebase/comments/14cj7au/firebase_...)
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.
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]
[1] https://www.sec.gov/Archives/edgar/data/1652044/000165204423...
[2] https://www.sec.gov/Archives/edgar/data/1652044/000165204423...
edit: formatting
From a documentation perspective, AWS is still the best.
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.
how would any reasonable person know what https://registry.terraform.io/providers/hashicorp/google/5.3... to enable without (a) trying it and squinting at the error message (b) clicking on the API documentation <https://cloud.google.com/run/docs/reference/rest/v2/projects...> then realizing it, also, does not mention run.googleapis.com, click on "supported service endpoints" <https://cloud.google.com/run/docs/reference/rest#rest_endpoi...> and only then learning about https://cloud.google.com/run/docs/reference/rest#service:-ru...
Repeat for https://registry.terraform.io/providers/hashicorp/google/5.3... although in both cases I guess the astute reader may have spotted the run.googleapis.com in the forbidden service labels and cloudidentity.googleapis.com in the example
Since, to the best of my knowledge those bindings are auto generated <https://github.com/GoogleCloudPlatform/magic-modules#magic-m...>, I would hypothesize it is not insurmountable drop in the seemingly existing declaration of APIs required: https://github.com/GoogleCloudPlatform/magic-modules/blob/7d... https://github.com/GoogleCloudPlatform/magic-modules/blob/7d...
[1] https://cloud.google.com/batch/docs/create-run-job-using-ter...
[2] https://cloud.google.com/batch/docs/reference/rest/v1/projec... [3] https://cloud.google.com/batch/docs/create-run-job-storage#u... [4] https://github.com/GoogleCloudPlatform/batch-samples/tree/ma...
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.
https://cloud.google.com/python/docs/reference/container/lat...
Generated samples suck - take a look at the boto3 docs and see if they tell you to go look at code generated samples.
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.
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.
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.
5 minutes later, the "technical writing manager on GCP", makes a helpful comment on this thread.
Google do actually offer great support, I pay like $30 a month for it and I can speak with real engineers who give super detailed answers.
It’s just not free. But the paid offering is great in my experience.
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.
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.
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?
It was totally our fault and these were also no "hidden" docs.
There are often no examples at all, and when there are they only cover the "hello world" case.
Last I tried, the documented examples for Cloud Functions v2 simply did not work.
I am part of the central team that manages the provisioning users and accounts and billing.
AWS is miles ahead of how we can express what we want in accounting.
AWS reps are much much more knowledgeable and a pleasure to work with when it comes to billing.
Disclaimer: meshcloud sells a product for teams in that space
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.
Before Google kills products, they lose interest in them.
> Workspace customers (the paid business version of Google apps) finally had Hangouts removed in March 2022
And Google Domains..
And Google Cloud IoT Core..
And Google Go Links..
And Google Maps Coordinate..
...
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)
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.
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.
I don't really enjoy being on GCP for that reason, but I need it for BigQuery, so...
With AWS, we have our account manager, whom I can call and he actually has some powers and can fix and do stuff for us.
150 sized company in a small EU country. We have a silver enterprise contract.
I think paid may be relative with GCP.
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.
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.
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.
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.
Google Cloud felt easier and intuitive to get started with, so that's what I use now.
this is how aws became easy and fun for me[1]. a similar interface could exist for any provider.
heroku is right about picking the good parts and exposing only that as an interface.
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.
1: https://status.cloud.google.com/incidents/dS9ps52MUnxQfyDGPf...
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:
https://cloud.google.com/compute/docs/reference/rest/v1/inst...
Or a different page might call this with - as the location to globally fan-out instead of talking to a particular region's control plane:
https://cloud.google.com/functions/docs/reference/rest/v2/pr...
(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.
Source: I work on the GCP Console.
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.
As for Nitro - take a look at C3. https://cloud.google.com/blog/products/compute/introducing-c...
Disclosure: I work on GCE.
FYI, per https://cloud.google.com/blog/products/compute/introducing-c...
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
Disclosure: I work for 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.
Many ways where GCP excels over AWS - https://news.ycombinator.com/item?id=23124350 - May 2020 (39 comments)
But from the perspective of a CEO, we want
1. Talent hiring should be easy, so we can plan growth
2. There should be a good self service support for developers
3. Need good sales support in architecture and tech selection (when needed)
4. Need to be able to get through to support engineer in 5 mins or less (we use aws premium support)
5. Need single vendor (as much as possible).
We consume a lot if what aws has to offer - we use their workspaces, mac cloud, device farm, code commit etc
We did a proper shoot out. While aws has its idiosyncrasies- it’s light years ahead of Google and Microsoft
Ps. We use Gsuite (for the last decade) - teaching a live human used to a challenge - now it’s a major pain.
If we find a better alternative to Gmail, Gdocs (etc). I’d switch in a heartbeat.
Our story: https://news.ycombinator.com/item?id=35133917
Forget about the initial shutdown, how can you take 1 whole week to resolve something critical like this.
Even if Google is offering me $1mil cloud credits today I wouldn't risk my business with them anymore.
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.
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.
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.
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.
https://status.cloud.google.com/incidents/2uFuNdeK9xXSwY9w7c...
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
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 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.
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.
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)
- they started to have a CloudFormation replacement with Deployment Manager <https://cloud.google.com/deployment-manager/docs/configurati...> but, again, I cannot stress enough how GODDAMN STUPID this is: one must enable deployment manager to use it, and the way one does that is via gcloud, click ops <https://console.cloud.google.com/apis/library/deploymentmana...>, or terraform -- then, ha ha, you went through all that trouble but you can't create an IAM Role with it <https://cloud.google.com/deployment-manager/docs/configurati...> partially because it's not a supported resource type and partially because MUTATING ROLE BINDINGS IS A RACE-CONDITION EVENT
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
- cloud shell tutorials, which is basically the union of all of those: https://cloud.google.com/shell/docs/cloud-shell-tutorials/ov... although in that case they do actually go out of their way to allow one to create a Project, with the activated service APIs, during the tutorial: https://cloud.google.com/shell/docs/cloud-shell-tutorials/di...
This article is three years old. Vertex did not even exist then.
Funnily enough, I would recommend AWS over GCP in every single category except for the two that you mentioned.
Although Snowflake is my choice for DW and it is cloud agnostic
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.
CamelCaseButWhichOne?
gcloud --butwhichone --orIsitThisOne --No-Dammit-Its-In-YAML=./yaml-fileThe 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.
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.
Medium sized company with low fluctuation of engineers.
https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
(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
How AWS is still stuck at the coasts is beyond me.
Edit: looks Iowa and Texas and Ohio as well for GCP
GCP is Omaha in Iowa.
So again what is AWS doing for multiplayer gaming?
GCP is F-tier
GCP - Shutdown our production servers and took 1 whole week to get it resolved. Nothing fraudulent on our end. Just for missing out on KYC form.
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.
DynamoDB Streams is also not a separate service. It's a feature of DynamoDB - streams data capture streams from a database. Exactly like... https://cloud.google.com/bigtable/docs/change-streams-overvi...
> 2019 Update: Amazon has now released another streaming service: Amazon Managed Streaming Kafka.
GCP also has a Managed Kafka service only theirs is a collaboration with Confluent: https://cloud.google.com/learn/what-is-apache-kafka
"Confluent Cloud on Google Cloud provides fully managed Apache Kafka as a service so you can focus on building apps and not managing clusters."
There is probably a rational reason for this behavior, but I don’t care. Just tell me the error.
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.
I want to predict behavior and Google has always been a little too hermetic and occult for my taste.
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.
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.
Likewise, as a GCP customer, I've always had a real account rep and support I could talk to.
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.
That's what I thought for a long time about google domains. Yet here we are.
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...
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.
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.
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.
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.
[1] https://cloud.google.com/domains/docs/deprecations/feature-d...
Selling to another company != shut down in my book. Although I'm already in the process of moving domains to another registrar...
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.
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.
[1] https://www.theregister.com/2023/06/18/google_domains_shutti....
If the onion released an article that states "Google sells it's domain business, who needs domains in 2023 anyway" this would be a great joke.
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.
Ones I have personal experience with include Stadia (paid), and app maker (business).
https://killedbygoogle.com/ doesn't struggle to find content.
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".
Google is reaping what it sowed.
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"?
Not likely.
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.
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.
One year later, Google Graveyard.
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 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.
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.
* 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.
https://www.allthingsdistributed.com/2023/09/farewell-ec2-cl...
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.
Potentially apocryphal, but it rings true enough that you have no idea what might anger the Google automation.
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.
No chance I'll ever vender lock myself to GCP.
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).
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).
Again, I'm willing to be wrong about recent reality, but GCP does not have a good reputation with its customers.
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".
What gets me is that AWS must have insane turnover with the Amazon stack ranking. The stability of that platform long term concerns me.
AWS is a utility at this point. Utilities are boring, conservative, and have people that know their systems and stay there for decades.
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.
It might adds negative credibility on HN.
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.
[1] https://www.theinformation.com/articles/google-brass-set-202...
But I generally agree with what you’re saying
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.
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.
So it's true that Ford US manufacturing have exited sedan production, Ford itself continues to build and sell sedans.
https://www.autotrader.com/archive/european-shoppers-also-so...
Ford China also isn't really launching new sedan models under the Ford brand. However, Ford is still making sedans worldwide under the Mustang brand.
In 2019 GCP was generating $9b/yr revenue, making it second largest revenue source, and the fastest growing one.
AWS is basically the same infra Amazon runs their own business on, opened up for the world to use.
Azure is the backbone that Microsoft sells you all their cloudified Office/Outlook/etc suite of tools.
GCP is neither of those things to Google.
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-...
Google Colossus file system underpins all storage across Google services and GCP Cloud Storage. https://cloud.google.com/blog/products/storage-data-transfer...
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/
https://www.cnbc.com/2021/06/04/google-is-moving-parts-of-yo...
With GCP I feel like you should stick to the core services to avoid any risks.
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.
If anything, they have been too eager to talk when I had nothing to discuss with them.
But my complain about product stability and maturity remains and that's admittedly is subjective.
Even if it's just to assuage fears.
From a business model perspective both these two entities are an aberration in how far they are from their corporate umbrella.
Microsoft, IBM, Oracle etc are more natural players in this domain but DigitalOcean shows you don't need to be bigtech to carve a niche.
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.
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.
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 :)
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
- 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.
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.
Well, just my 0.02. What do I know, right?
>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.
Would your stake in VMware and AWS not be {threatened,weakened}, perhaps severely, should Google succeed in Cloud?