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

81–90 of 202 posts

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

#81

Post by mmclean »

dantiberian wrote: post #19
ebikelaw wrote: post #9

Earlier quoted context omitted.

Also familiar: monitoring frontend is tragic-comic with no units and inscrutable data. It’s cute that the author thinks the internal version must be a lot better! On the other hand, the article doesn’t mention Stackdriver Profiler, which has an amazing UX. Definitely recommended if you are spending significant money on CPU at GCE.

Nice, I haven't used the Profiler yet, will check that out soon. What languages have you used it with? I'm looking to use it with the JVM profiler.

[SD APM PM here] Yep, we support Java / JVM, Node.js, and Go; Python is coming soon

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

#82

Post by csmiller »

fredliu wrote: post #68

I see lots of evaluation of GCP, or comparison between GCP vs AWS recently. But I don't see as many for the Azure platform, although Azure being the 2nd in the cloud provider market, and even closing on AWS in market share. Anybody has any insights on this?

Just a wild guess, but I think the people who use Azure use it for its compliance/security features, and people who need those may not be the most forthcoming about their applications. (Governments, Banks, etc)

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

#83

Post by Jonovono »

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…

Ya, we love Firebase! Use Firebase functions heavily and i've been very pleased. That tied with redux works so smoothly. It's a different way of thinking about things but I find it so much easier to maintain and reason about than your conventional rest service.

Couple things I wish it had:

1. Ability to `keepalive` certain functions. Cold start is real. We have gotten around this via app engine cron that triggers certain functions.

2. Schedule them on cron. We have gotten around this using app engine.

If curious, this is what we are building off of Firebase (and React native) https://itunes.apple.com/us/app/bunch-group-video-chat-games...

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

#84

Post by willcodeforfoo »

Seconding the issues on the Load Balancer and 502s. We moved our app there earlier this year to take advantage of GKE and just sort of put up with random 502s (especially during deployments, which are supposed to be zero-downtime). We contacted Google Support but they were unable to help and said that yeah, some percentage of dropped requests is fine. I suppose it's something with our Rails app or configuration, but no one was able to help and I decided to stop wasting time trying to fix it.

They have more-or-less gone away now but several months later it leaves me with very little confidence in GLBs and quite scared to change anything around.

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

#85

Post by exhilaration »

fredliu wrote: post #68

I see lots of evaluation of GCP, or comparison between GCP vs AWS recently. But I don't see as many for the Azure platform, although Azure being the 2nd in the cloud provider market, and even closing on AWS in market share. Anybody has any insights on this?

I have a feeling that most of us working with Azure are employed by large corporations outside of Silicon Valley / FAANG. And we're poorly represented on Hacker News.

Microsoft's bread and butter was always the Fortune 500's and I have the impression that's where they're making most of their Azure sales.

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

#86

Post by merb »

sethvargo wrote: post #50
theptip wrote: post #36

Earlier quoted context omitted.

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…

I'm trying to reproduce the Cloud SQL Proxy in Cloud Shell that both you and the OP have mentioned, but I've been unable to reproduce (and thus file a bug). I'm sure I'm missing a step. If you're willing, I would love if you could drop me a quick note (sethvargo at google dot com) with the steps you're taking, commands you're running, and output you're seeing. This will help me escalate it to the right team. I'm also…

the biggest problem I had with cloud sql proxy or cloud sql in generell is that postgresql is limited to 100 connections. since I'm a small customer hosting many low traffic projects I want to share my instance as much as possible, however running pgbouncer for a lot of ups is painful since cloudsql does not allow to query the auth table (what's used by pgbouncer if you don't add all database username/password on your own).

I think a lot of problems would be solved if there would be a way to setup cloud sql proxy that comes with transaction pooling, especially when using k8s and having a pooling namespace (multiple load balancers for HA) where all other apps connect to.

also cloud sql and ipv6 is not funny. (i.e. a lot of things in gcp is ipv4 only which is sad)

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

#87

Post by theptip »

sethvargo wrote: post #50
theptip wrote: post #36

Earlier quoted context omitted.

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…

I'm trying to reproduce the Cloud SQL Proxy in Cloud Shell that both you and the OP have mentioned, but I've been unable to reproduce (and thus file a bug). I'm sure I'm missing a step. If you're willing, I would love if you could drop me a quick note (sethvargo at google dot com) with the steps you're taking, commands you're running, and output you're seeing. This will help me escalate it to the right team. I'm also…

Just to clarify with some more detail (for the HN record), the issue with Cloud SQL is that while you can whitelist an individual internal IP, you can't whitelist an internal network (like 10/8). This means you need a sidecar service of some sort to add the whitelist rules when a new instance/pod comes up that should be able to access the DB.

In AWS for a simple app I'd just whitelist 10/8 and have the DB open to all internal instances (with TLS for added security as required).

I'll follow up by email too, happy to provide detailed feedback on this sort of thing.

Thanks for taking the time to engage with the community on this stuff!

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

#88

Post by QuercusMax »

amorphid wrote: post #42
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.

I haven't tried this myself, but could you have your client(s) get around this via multipart upload?

I don't think you mean multipart upload - that's a single request that contains multiple files. You're talking about some kind of resumable uploads.

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

#89

Post by 4di »

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…

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

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

#90

Post by meeks »

optimusclimb wrote: post #57
bduerst wrote: post #48

Earlier quoted context omitted.

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…

To conclude that:

> Google couldn't care less if their customers can figure out how to use their products.

That feels like a pretty strong leap to make from your complaint about using the term "reload" when "load" is better.

I can understand you are providing an example, and perhaps you feel the documentation has many such examples. From personal experience reading extensive documentation, I think you are being slightly unfair in this instance.

If I had to guess, given the speed of development of Google Cloud, it will take some time to get to the level of mature documentation of AWS who has had years of head start.

Post reply on HN