Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Cloud Platform – The Good, Bad, and Ugly

deps.co

Post reply on HN
Print view View original

51–60 of 202 posts

Re: Google Cloud Platform – The Good, Bad, and Ugly

#51

Post by clhodapp »

jrockway wrote: post #5

> Sometimes when browsing documentation for a service or API you will find that the old way is deprecated, but the new way that they recommend you use is still in beta or alpha (!). Familiar.

"Beta" is kind of an awful purgatory state on GCP. We all know that most of their beta stuff is actually really well-tested and stable (it's even mentioned in this article). They also know it themselves and seem to assume that people will be willing to start using their products when they are in beta. However, they have an ill-advised blanket policy that beta products are not covered by SLAs, which ends up meaning that no responsible decision-maker wants to build anything in production on top of anything tagged "beta". In many ways, you get forced to treat beta in exactly the same way as alpha even though you know that it's actually much more reliable. I strongly believe that Google and its users would be much better off if Google used beta to mean "SLA'd but with documented feature gaps and a shortened deprecation period" and kept stuff that they are not willing to SLA in alpha.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#52

Post by sethvargo »

optimusclimb wrote: post #32
sethvargo wrote: post #27

Hey there! Seth from Google here. Thank you for writing up this article and providing this valuable feedback - we really appreciate it. I’m personally taking this feedback and making sure it’s shared with the relevant teams (both positive and negative). On the DevRel team at Google, we often write friction logs (my colleague just authored a post about friction logs in detail: https://devrel.net/developer-experience/a…

Had to use the cloud storage python API yesterday to retrieve the sizes of many blobs I have stored there. First time using said API. Creating the client was straight forward enough...oh look, there is a section of the API docs on Blobs, cool - create a blob...and there's a size property. And it has no data. Scan through ALL of the docs on the page...ahh, there's a "reload()" method, and sure enough, calling it retri…

Thanks for sharing your experience. This is definitely not the feelings we want users to experience. If you remember, could you share the documentation page(s) you were on? I'll make sure they are updated to reflect the proper fields and steps to take.

We do care deeply about our users' experiences with both GCP and the GCP ecosystem. Feel free to send me specific areas where you've experience pain in the past and I'll get them addressed (email is the same as my handle - at google - dot com)

Re: Google Cloud Platform – The Good, Bad, and Ugly

#53

Post by sethvargo »

magsafe wrote: post #38

One thing I didn't see mentioned in this article is Firebase. It feels like a hidden gem lurking within the overall GCP offering, and may be overlooked by devs who're not doing mobile-specific work. For me, Firebase was the gateway drug that got me into GCP. I successfully built and hosted the backends for a couple of iOS apps using Firebase. The best parts were cloud functions and built-in sync (including offline/oc…

Thank you for the kind words. I'll make sure the firebase teams receive it :)

Re: Google Cloud Platform – The Good, Bad, and Ugly

#54

Post by dantiberian »

neya wrote: post #43
dantiberian wrote: post #40

Earlier quoted context omitted.

I looked long and hard at App Engine, but I wasn't able to use it as I needed to be able to accept file uploads that were larger than the upload limit on the App Engine load balancer. Otherwise it likely would have been my choice. I'm looking at using it for some internal applications soon though.

If you're trying file uploads that directly sit within your application, AppEngine (sort of) discourages that, the right approach would be to let your app upload the files to a CDN (like google cloud storage, if you're on GCP) and manage access through ACLs.

Yeah, the issue (which I didn't explain well) is that Deps is a Maven repository and needs to speak the Maven protocol. That makes it difficult to do the ACL signing for direct uploads, especially if I want to make it clean for users configuring it.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#55

Post by stefano »

dantiberian wrote: post #40
neya wrote: post #37

Although the author mentions they haven't had experience with AppEngine, it's the reason why I love Google Cloud SO much over anything else. If you're a startup running something on Elixir (or even Rails), AppEngine's experience is hard to beat. Not many people do know: * You can run multiple microservices on AppEngine under one application. * Each of these can have many versions serving different percentages of traf…

I looked long and hard at App Engine, but I wasn't able to use it as I needed to be able to accept file uploads that were larger than the upload limit on the App Engine load balancer. Otherwise it likely would have been my choice. I'm looking at using it for some internal applications soon though.

The only way to do that on App Engine is to have the client ask the server for a temporary signed URL to a writable cloud storage resource, and then have the client upload to that URL (i.e. the only way is by sidestepping App Engine...).

Re: Google Cloud Platform – The Good, Bad, and Ugly

#56

Post by stefano »

dantiberian wrote: post #54
neya wrote: post #43

Earlier quoted context omitted.

If you're trying file uploads that directly sit within your application, AppEngine (sort of) discourages that, the right approach would be to let your app upload the files to a CDN (like google cloud storage, if you're on GCP) and manage access through ACLs.

Yeah, the issue (which I didn't explain well) is that Deps is a Maven repository and needs to speak the Maven protocol. That makes it difficult to do the ACL signing for direct uploads, especially if I want to make it clean for users configuring it.

You can have the client upload to a cloud storage bucket, then notify the server that the file is ready. Upon receiving the notification, the server can start a background task that reads the file from the bucket and uploads it to the Maven repository.

It's a few extra steps for something that should be simpler, but it's workable.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#57

Post by optimusclimb »

bduerst wrote: post #48
optimusclimb wrote: post #32

Earlier quoted context omitted.

Had to use the cloud storage python API yesterday to retrieve the sizes of many blobs I have stored there. First time using said API. Creating the client was straight forward enough...oh look, there is a section of the API docs on Blobs, cool - create a blob...and there's a size property. And it has no data. Scan through ALL of the docs on the page...ahh, there's a "reload()" method, and sure enough, calling it retri…

Can you point to which docs were you using? On github it says that if it reports 'none' then you need to load the resource. https://googlecloudplatform.github.io/google-cloud-python/la...

Was reading that page. What it specifically says is:

> The size of the blob or None if the blob’s resource has not been loaded from the server.

That's pretty vague imho, because there is no high level overview or tutorial to tell you that you need to explicitly cause the load from the server. Point in fact, the function you need to use is "reload()", and the documentation of this func is "Reload properties from Cloud Storage." To me, the "re" part makes it a bit of a misnomer - as it implies there would have been some sort of initial load in the first place (there is not.)

Imagine if the interface for going to a web page in chrome was: 1. Type the URL in the location bar. 2. Hit "refresh."

Re: Google Cloud Platform – The Good, Bad, and Ugly

#58

Post by whoisjuan »

Most of the AWS complexity issues that the author mentions are actually enterprise / high-scale features.

Sure, they are too complicated and unnecessary for small operations, but many large organizations wouldn't even consider a cloud infrastructure provider without those things (comprehensive permission and identity model, discernible region and inter-region model, breadth, and depth in computing types, highly auditable security model, etc...)

I get his points, but all the things he claims are great about GCP are only great for a one-man shop and not for an enterprise operation.

Re: Google Cloud Platform – The Good, Bad, and Ugly

#60

Post by optimusclimb »

sethvargo wrote: post #52
optimusclimb wrote: post #32

Earlier quoted context omitted.

Had to use the cloud storage python API yesterday to retrieve the sizes of many blobs I have stored there. First time using said API. Creating the client was straight forward enough...oh look, there is a section of the API docs on Blobs, cool - create a blob...and there's a size property. And it has no data. Scan through ALL of the docs on the page...ahh, there's a "reload()" method, and sure enough, calling it retri…

Thanks for sharing your experience. This is definitely not the feelings we want users to experience. If you remember, could you share the documentation page(s) you were on? I'll make sure they are updated to reflect the proper fields and steps to take. We do care deeply about our users' experiences with both GCP and the GCP ecosystem. Feel free to send me specific areas where you've experience pain in the past and I'…

Thanks for the response. See my response to bduerst in this same thread - it was that page.

Also to be clear - I don't think this particular example I gave is the end of the world/egregious - I just used it as representative of the fact that the general pattern I've seen of the docs following where details are explained, but the "obvious" bits of simple usage are not discussed.

Post reply on HN