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.
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.
Speaking more generally, it seems AWS is allergic to creating products that scale to zero nowadays.
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.
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
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.)
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.
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.
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.
Apparently some of the key people behind BQ are now working on MotherDuck, which is a cloud data warehouse version of DuckDB.
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)
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.
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.
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.
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...
Whether or not they'll continue to lose billions a year for Google I can't say.
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...
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.
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."
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.
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.
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.
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
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.
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.
GCP support also provides the answers I need.
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
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.
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.
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.
[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...
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...
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.
From a documentation perspective, AWS is still the best.
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.
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.
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.
Disclaimer: meshcloud sells a product for teams in that space
Before Google kills products, they lose interest in them.
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.
I don't really enjoy being on GCP for that reason, but I need it for BigQuery, so...
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.
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.
I think paid may be relative with GCP.
> 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..
...
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.
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.
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
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.
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...
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.
But I generally agree with what you’re saying
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.
In 2019 GCP was generating $9b/yr revenue, making it second largest revenue source, and the fastest growing one.
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.
* 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...
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.
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).
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.
One year later, Google Graveyard.
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).
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.
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.
Potentially apocryphal, but it rings true enough that you have no idea what might anger the Google automation.
Ones I have personal experience with include Stadia (paid), and app maker (business).
https://killedbygoogle.com/ doesn't struggle to find content.
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.
That's what I thought for a long time about google domains. Yet here we are.
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...
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.
Again, I'm willing to be wrong about recent reality, but GCP does not have a good reputation with its customers.
It might adds negative credibility on HN.
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.
Likewise, as a GCP customer, I've always had a real account rep and support I could talk to.
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.
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.
Even if it's just to assuage fears.
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.
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.
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.
Would your stake in VMware and AWS not be {threatened,weakened}, perhaps severely, should Google succeed in Cloud?
> 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.