Live data from Hacker News

Google Cloud Platform – The Good, Bad, and Ugly

deps.co

61–70 of 202 posts

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

#61
post #45

Earlier quoted context omitted.

In that case, if you're on AWS, then why not just use CloudFormation? CloudFormation is a lot more powerful on AWS than TF.

Because editing yaml or json sucks.

Linked from Hashicorp’s Getting Started page...

https://github.com/terraform-providers/terraform-provider-aw...

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

#62
post #56

Earlier quoted context omitted.

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.

The client in this case is Maven, SBT, Leiningen, e.t.c., so I don't think I can get that kind of control over how Maven would upload the files.

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

#63
Reading the comments here a persistent theme seems to be that the documentation is lacking. Something that might help is creating a "dog-fooding" team mostly filled with interns. This team will be responsible for creating samples with the public APIs. Why Interns? Because they will move on to better things around the time when their brains learn the patterns required to navigate the Google cloud API efficiently.

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

#64
post #39

Earlier quoted context omitted.

This is to push you towards CDNs. The main data centers cannot scale appropriately to serve high bandwidth applications, and aren't meant to.

I am not sure why this was downvoted. Isn't it true, that cloud storage service is supposed to be used for cloud storage , and content delivery service is supposed to be used for content delivery ?

Media content storage and delivery is an advertised use case [1]

> ...highest level of availability and performance is ideal for low-latency, high QPS content serving

And the cost using Google Cloud CDN isn't necessarily going to be a major improvement over Google Cloud Storage. Egress cost is similar depending on usage, plus you pay for cache fill and api calls.

[1] https://cloud.google.com/storage/use-cases/

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

#65
post #36

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…

Just to echo the OP -- the Cloud SQL proxy has been a pain point for me for years, it makes deploying to Kubernetes a PITA, since I have to use a different configuration vs. my dev setup. Whitelisting RDS networks inside the VPS is a feature that's existed in AWS for many many years. Also agree that Stackdriver is pretty underwhelming, though it does have the perk of providing zero-configuration log capture in GKE. L…

Thank you, this is very helpful because these little things are the stuff that you can’t find in any documentation but end up biting you in production.

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

#66
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…

App Engine is really awesome! There's a few caveats I would add if you're using it for Rails or Elixir which requires the Flex environment.

* No integration with Standard APIs

* Slow / build deploy times

* Minimum pricing of $40 per machine / month

Overall, I feel like the direction App Engine is headed makes it purely better than other PaaS services but if you're running a low traffic website that isn't standard environment (Java 7/8, Python 2.7, Node 8, PHP 5.5, Go 1.6/7/8/9), Heroku is probably still more economical and better developer ux.

I hope they add Ruby and Elixir to the standard environment. I don't think any other PaaS would compare.

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

#67
post #59

Hey, I work on public-facing support for GCP. Given the point that it's hard to see what mailing lists are available I wanted to point out https://cloud.google.com/support/docs/groups It's definitely not as well-integrated as AWS' forums, but it's a starting point.

Thanks! I've just updated the post with that.

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

#69

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…

I have to say I 100% agree about the documentation.

Having used both GCP and AWS, although the core GCP offerings are fantastic and far superior to AWS, the GCP documentation is a disaster.

It’s totally inexcusable, and really disappointing because it has a huge effect on the perception of the platform among folks that are AWS users and take a quick look at GCP.

I can’t see any reason why the documentation issue shouldn’t be solvable in 3 months with enough money. Take a wheelbarrow down to the bank, fill it up, and put out an open offer to everyone on the AWS documentation and developer relations teams to double their salary and stock.

The core of GCP is so great, that it’s such a shame the final polish seems to be impossible to accomplish.

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

#70

Reading the comments here a persistent theme seems to be that the documentation is lacking. Something that might help is creating a "dog-fooding" team mostly filled with interns. This team will be responsible for creating samples with the public APIs. Why Interns? Because they will move on to better things around the time when their brains learn the patterns required to navigate the Google cloud API efficiently.

Yes! The documentation problem is NOT complex to solve. I would love to use GCP on more projects but the docs are embarrassing.

Are they trying to get engineers to write the docs rather than hiring professional technical writers?

Truly baffling.

Post reply on HN