Sure muggles don't care about Google dropping services.

My experience is that Google services are often an order of magnitude harder to use than competitors.

For example I did a shootout between the visual recognition APIs from IBM, Amazon, clarif.ai, Google and some others.

I had the other ones up and running in under ten minutes each.

Google made me go through a sign-up and authentication process that looked like

https://www.youtube.com/watch?v=sWEvp217Tzw

and then installing their Python SDK trashed my Python installation and forced me to reinstall anaconda.

I think Google is used to hiring people with 130+ IQs and wasting their cognitive capacity and they would love to make you waste your cognitive capacity too.

> My experience is that Google services are often an order of magnitude harder to use than competitors.

Huh, I think most people feel the exact opposite, especially with the comparison between AWS and GCP. GCP has lots of services that are really easy to get set up and running easily by a small Dev shop (Firebase is pretty fantastic in my opinion), while with AWS unless you have some DevOps/networking experts it's a lot harder to do things correctly and securely.

If anything, I think the biggest issue with GCP is they still don't have the "DNA" to do enterprise support at the level large companies expect, while AWS does.

> I think the biggest issue with GCP is they still don't have the "DNA" to do enterprise support at the level large companies expect, while AWS does.

You nailed it. Coming from 8-years of AWS and working on GCP for the last 4, enterprise support is the BIGGEST differentiator IMO between AWS and GCP. GCP's services are usually technical advanced sooner (encryption architecture, various of compliances certification, etc.) and more developer friendlier, their support is absolutely the worst in the industry, opaque, slow and hard to reach, just like the support from any other Google consumer facing products. Google has never been a consumer friendly technology company, probably never will. This is in dire contrast with Amazon, which Bezos claim it always has been a customer focused business.

Well I wouldn't say their consumer facing products are bad. We've spend $70mil a year with them for google ads and I would say their support for Ads are fantastic.

Google's quality of support tends to correlate strongly with how much money you pay them. They treat their large advertisers very well, but for that very same product, support under $1mil/year is pretty bad, and that's actually still quite a bit of spend.

True. AWS enterprise support varies based not on how much money you spent on the account but rather how much money you opt-in on the support tier - the top tier support contract is expensive but AWS really treats you like a partner with prompt updates on the issue resolution, sometimes live support over the phone to tell you how to debug and identify issues.

What about Google support? Nada. They don't even have a direct phone number to reach (requests are sent via email). There are issues that they completely dropped the ball on and provide no updates whatsoever or reluctant to look into or to put a closure on. Day and night difference. (We weren't a $1MM account in terms of total annual GCP spending just yet, we very well could be in the next years I hope.)

yeah completely agree.

That's not a consumer product, that's their core business. Also you need to spend over 1M/month to get any real support.

My experience, and the experience of everyone I've talked to, is that Google support is amazing if you pay for it, and nearly non-existent if you don't.

You may check this Single API to a bunch of visual recognition services, in case you still need it: https://inten.to/api-platform/ai/image/tagging

I think GCP for plain infra stuff is complicated, but so is AWS. They’re about the same to me, but AWS seems to have vastly more features.

Anecdotal evidences are great. It is not an accident that GCP and Azure storage service has a S3 API and not the other way around.

https://cloud.google.com/storage/docs/interoperability

https://www.microsoft.com/developerblog/2016/05/22/access-az...

S3 API compatibility is there because creators of open source "data engineering" tools have in the early days rushed to develop their tools around the S3 API. I can make the case that the need for a properly abstracted storage layer should have been obvious, but in that early gold rush no one would have listened to such reason. Nowadays vendors are stuck shipping S3 compatibility layers in order to avoid locking out tools that cannot work without S3.

If you think I'm wrong, imagine for a moment what life would be like if every RDBMS client in existence got written in terms of Oracle's wire protocol, back when Oracle's RDBMS offering dominated its respective market. Thankfully that parallel universe is somebody else's problem right now, but it could have happened.

Not at all. It is there because AWS's S3 became the defacto solution for storage and because they were first AND also because of popularity and how well it works.

Your Oracle example is flawed for many reasons. SQL standard pre-dates Oracle and I am not even sure what you mean by every RDBMS client got written in Oracle's wire protocol. Ingres also predates Oracle. Are you implying that S3 API is there because they were the first? Nothing else?

https://en.wikipedia.org/wiki/Ingres_(database)#Early_histor...

SQL standard:

Developer ISO/IEC First appeared 1974; 45 years ago

Oracle first release: Oracle v2 2.3 1979

And also, it is allowed and trivial to implement S3 APIs because it is well documented and available for anybody. You are also implying that S3 API is not a "properly abstracted storage layer"?

Save the Wikipedia links: surely you remember the time when database selection boiled down to "Oracle or bust". I'm not implying that S3 was first & dominant early on: I'm stating it as a flat fact.

Yes, many RDBMS offerings have preceded Oracle, but none gained such wide adoption early on. Oracle has always had a strong sales team, so they've been able to grow their business rapidly. Good for them. SQL standardization has nothing to do with it either, because SQL is the user-facing language, not a wire protocol. What travels over the wire between an Oracle client and the server has about as much to do with SQL as the S3 API has to do with XML.

In your rush to defend AWS you seem to be falling into the same trap of immaturity as the people who have assumed that S3 will always remain the one true storage layer. It is not your fault, just a sign of the times. You're part of the generally apparent downward trend in level-headed, long-term thinking among the software cadre. For your next project, I recommend that you keep in mind that proper abstractions and clearly defined interfaces are crucial for maintainability of software over the long term. Good luck!

>It is not an accident that GCP and Azure storage service has a S3 API and not the other way around.

both look like third party projects rather than something by Google/msft. saying that "gcp/azure has a s3 API" would be like saying "Linux has a win32 API" because there's WINE.

S3Proxy is third-party, but Google's GCS S3 compatiblity is very much native. It was a selling point when they first launched it that you could just take boto and change the endpoint, add a header, and have it work.