4 ms·

I've built applications on AWS, IBM Cloud (Bluemix at the time), Azure, and GCP. If a client has no preference over platform, I usually go with GCP. I find it t

I've built applications on AWS, IBM Cloud (Bluemix at the time), Azure, and GCP. If a client has no preference over platform, I usually go with GCP. I find it the simplest, cheapest, and most reliable for the type of stack we use. I've never had a client question GCP on the basis of Google's pattern of removing services. I think people can logically separate Google's consumer-facing offerings from their paid cloud services, the same way people logically separate AWS from the Amazon store. I've never noticed a GCP service removed in the nearly 10 years I've used them. In fact, the pattern I see with GCP is that they're slower to add services , but the ones they do release are very well thought out and solid. AWS, on the other hand, seems to add tons of services, some of which are incomplete or never get traction. I would happily use either AWS or GCP. IBM Cloud and Azure I'm far less inclined to use, although I can understand Microsoft shops wanting to use Azure. IBM Cloud is pointless.

StreamBright 8y ago
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://cloud.google.com/storage/docs/interoperability https://www.microsoft.com/developerblog/2016/05/22/access-azure-blob-storage-from-your-apps-using-s3-api/ https://www.microsoft.com/developerblog/2016/05/22/access-az...
- deleted 8y ago
  [deleted]
- sigfubar 8y ago
  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.
  - StreamBright 8y ago
    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_history 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"?
    - sigfubar 8y ago
      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!
- gruez 8y ago
  >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.
  - apetresc 8y ago
    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.
PaulHoule 8y ago
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 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.
- hn_throwaway_99 8y ago
  > 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.
  - devy 8y ago
    > 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.

StreamBright 8y ago

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://cloud.google.com/storage/docs/interoperability https://www.microsoft.com/developerblog/2016/05/22/access-azure-blob-storage-from-your-apps-using-s3-api/ https://www.microsoft.com/developerblog/2016/05/22/access-az...

deleted 8y ago
[deleted]
sigfubar 8y ago
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.
- StreamBright 8y ago
  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_history 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"?
  - sigfubar 8y ago
    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!
gruez 8y ago
>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.
- apetresc 8y ago
  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.

PaulHoule 8y ago

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 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.

hn_throwaway_99 8y ago
> 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.
- devy 8y ago
  > 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.