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

161–170 of 202 posts

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

#161

Post by sanatgersappa »

itcmcgrath wrote: post #143
kart23 wrote: post #142

Earlier quoted context omitted.

Firebase is great, but in my little experience, as it's database grows, it becomes clunky to sort and query, especially since everything is pretty much done client side.

Try Cloud Firestore, it has a lot of improvements with querying over the RTDB. I can also confirm sorting/querying is handled server-side. (Disclaimer: I'm the PM for it and use it for my own side-projects)

Would be even better if there was a graphql frontend like AWS AppSync. Helps structure the data a lot more easily.

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

#162

Post by esseti »

dantiberian wrote: post #14
ebikelaw wrote: post #10

Earlier quoted context omitted.

I guess that closeness to user got eliminated from the “good” list since Google’s FELB is serving 502 to this author’s customers.

They did eventually stop serving sporadic 502's, I've updated the post to make that a bit clearer.

OP: for the 502 problems give a look at this https://github.com/kubernetes/ingress-nginx/issues/1396 https://github.com/kubernetes/ingress-gce/issues/34

I run into the same problem while ago. It may solve your problem as well.

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

#163

Post by mustacheemperor »

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'…

Seth, thanks for taking the feedback directly here, but...

Shouldn't we be able to make these requests given the built in feedback tools in the documentation, and actually expect some result? It's great that you're willing to address this specific issue, but it's frustrating to basically see plain text validation that the feedback forms are not attended to, and developers should be emailing individual team members problematic documentation pages if we're in the cohort exposed to your contact information.

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

#164

Post by KajMagnus »

scarface74 wrote: post #97
marcinzm wrote: post #80

Earlier quoted context omitted.

Which is neither json or yaml...

It's yet another semi-json format that doesn't have widespread support by any other parsers. Even Hashicorp recommends JSON if you want something that is machine readable.

I think it looks lovely :- ) having used Puppet a bit in the past. Look how simple: `inline = ["sudo apt-get -y update", ... install nginx ...` Terraform seems to be. .... hmm, apparently one can use things like Chef & Puppet etc together with Terraform, I eventually noticed.

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

#165

Post by skywhopper »

scarface74 wrote: post #26

I keep hearing how great Terraform is because it allows you to treat infrastructure as code in a cloud agnostic manner. But every time I see a Terraform script, it's tied tightly to AWS's infrastructure -- including Hashicorp's own examples.

Terraform doesn’t abstract away the details of which cloud provider you are using. That would be impractical if not impossible for anything beyond trivial use cases. But it does let you abstract away the logic in dealing with maintaining infrastructure that’s managed through APIs. And the provider support for each cloud makes a huge difference in how usable it is. The AWS support is generally great so I assume the GCP support here is as well.

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

#166

Post by gm-conspiracy »

neospice wrote: post #124
4di wrote: post #89

Earlier quoted context omitted.

Have you migrated anything off of Firebase? Or still kept the “base” projects and upgraded around it? I’m interested specifically in how expensive Firebase is for popular products

I haven't migrated off of Firebase but this is something I've thought a lot about as I've selected Firebase for many of my client projects. As far as I can tell there is no open-source alternative with feature parity that makes it easy to migrate away from Firebase. I'd be curious to hear about how people have done this.

Is Parse on node comparable at all?

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

#167

Post by foota »

dantiberian wrote: post #62
stefano wrote: post #56

Earlier quoted context omitted.

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.

I'm curious, could you use a 307 redirect to redirect the user agent to a signed upload URL?

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

#168

Post by mezzode »

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…

I've heard that while Firebase is good, it has pretty high pricing once you have enough users and has a big vendor lock-in problem.

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

#169

Post by ProblemFactory »

madrox wrote: post #109
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…

Firebase is great, but covered under a separate agreement with Google, and its terms aren't as friendly to corporate users. For example, they still aren't encrypting tenant data at REST. Nothing is COPPA compliant.

> encrypting tenant data at rest

I know that this is required by various security certifications - but is there a reasonable threat model that it actually protects against?

The only one I see is someone physically stealing the hard disks out of the servers, which is impossible if you are using a trustworthy cloud datacenter instead of a server in your bedroom.

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

#170

Post by ciguy »

outworlder wrote: post #132
sethrin wrote: post #118

Earlier quoted context omitted.

Why should one not run Terraform locally?

Not the parent, but I share the same opinion. You totally can run locally, provided you are a single developer in your project. Once you start collaborating, you need this to be in a CI server or similar. Make it in such a way that the code is guaranteed to be properly versioned, taking the latest from your 'production' branch, as you can run into a situation where you are running terraform based on local changes whi…

Agree 100% with all this.
Post reply on HN