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

181–190 of 202 posts

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

#181

Post by briffle »

briffle wrote: post #172
sethvargo wrote: post #28

Earlier quoted context omitted.

Hey there - Seth from Google here. We have a dedicated team of Google engineers who contribute to Terraform as their full time job. We are constantly looking for ways to improve. We added a lot of examples to our Google provider documentation, and we are working on a project that will enable us to add support for new GCP features in Terraform faster. I can’t speak for HashiCorp’s own examples (I mean, I could, I used…

We use terraform to create our new projects, but with them not supporting kubernetes deployments it would be very difficult for us to continue to use them after standup. (I then script kubectl commands to create our deployments, etc.) Their own github repo issue list said they wouldn't support deployments when it was in beta (hashicorp won't do anything that is in beta, another problem with google cloud and its long,…

I should have included this earlier: https://github.com/terraform-providers/terraform-provider-ku...

Deployments have been in GA 7 months now, and NO feedback from hashicorp on this one...

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

#182

Post by fasteo »

atombender wrote: post #178
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…

If you like Firebase, I'd like to give a shout-out to Sanity [1]. (Disclosure: I work part-time on the backend, but I'm not an employee and I don't work on the product itself; but call this a shameless plug if you will!) Sanity is a headless CMS, but the API itself is like a souped-up Firebase and can be used on its own without adopting the Sanity UI. It's got many of the same features -- web API, change watching via…

Thanks for the pointer to sanity. After a quick read over the docs, it seems a really impressive piece of software.

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

#183

Post by sethvargo »

briffle wrote: post #181
briffle wrote: post #172

Earlier quoted context omitted.

We use terraform to create our new projects, but with them not supporting kubernetes deployments it would be very difficult for us to continue to use them after standup. (I then script kubectl commands to create our deployments, etc.) Their own github repo issue list said they wouldn't support deployments when it was in beta (hashicorp won't do anything that is in beta, another problem with google cloud and its long,…

I should have included this earlier: https://github.com/terraform-providers/terraform-provider-ku... Deployments have been in GA 7 months now, and NO feedback from hashicorp on this one...

:) This one actually personally bothers me too. I have a really hacky shell-out to kubectl because deployments aren't currently supported, so I definitely empathize here. That being said, Google doesn't currently maintain the Kubernetes provider for Terraform; it's entirely maintained by HashiCorp.

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

#184

Post by madrox »

tylerl wrote: post #134
madrox wrote: post #109

Earlier quoted context omitted.

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.

I'm pretty sure that's wrong. Also: https://cloud.google.com/firestore/docs/server-side-encrypti... "Each Cloud Firestore object's data and metadata is encrypted under the 256-bit Advanced Encryption Standard, and each encryption key is itself encrypted with a regularly rotated set of master keys." So... yup.

Wow, sounds like my info is out of date! This was true when we last evaluated it. I really do appreciate how fast Google is on this stuff.

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

#185

Post by madrox »

ProblemFactory wrote: post #169
madrox wrote: post #109

Earlier quoted context omitted.

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.

If you have customer-managed keys like parts of Google Cloud, it keeps even Google from reading your data on disk.

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

#186

Post by madrox »

itcmcgrath wrote: post #145
madrox wrote: post #109

Earlier quoted context omitted.

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.

I lot has changed in the last year or so, might be worth looking again. Most of the backend services are under GCP's terms of service, products like Cloud Firestore all do encryption at rest, etc.

It sounds like my info is out of date, which makes me very happy considering how much I love Firebase.

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

#187

Post by gizmodo59 »

Okay Google, I would like to report an outage in GKE.

Thanks for contacting Google AI support. We can't escalate this to a human because we don't have enough skilled support team but our AI can solve any problem and we use you as a training set. /s

(I know its harsh but I'm sure people here can relate to it)

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

#188

Post by tutanchamun »

fulafel wrote: post #156
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…

The generous free tier in App Engine is also very nice - lets you run a lot of personal / experimental stuff for free.

What happens if the free quotas are reached? Will the app terminate until the free quotas are available again, or will the user be billed?

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

#189

Post by atombender »

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…

We have similar experience with StackDriver Logging. It's felt unfinished since day one. Two problems come to mind:

(1) Some time ago I needed to get a month of logs (filtered by an expression) in order to compare the logged data against a database. The Console does not have any such option. You can set up "exporting", but that only starts replication from the moment you set it up; no historical data. You can use the APIs or "gcloud beta logging read", but the performance is terrible. I got maybe 200-500KB/sec. After keeping the command running continuously for 3 days (!), I still only had 20% of the log data.

These days, we have exporting set up to pipe all the logs into BigQuery and GCS, just to get around the crappiness. That gives some query capabilities, as well as the ability to quickly grab the original data for processing with other tools.

(2) We're on GKE, and none of the container's labels end up in log entries. Surely this is pretty key stuff. There seems to be no way to customize the payloads that GKE's Fluentd sends to StackDriver.

(3) There's no way to tail logs. The gcloud command doesn't have it, and the Console doesn't either. It feels like such a missed opportunity.

I think Google would be better off ditching StackDriver Logging entirely and instead let the user set up rules to send logs to different services that actually work. The default could be BigQuery. I don't understand the point of having a separate, proprietary query language for logs when you have SQL.

I've looked briefly at the other StackDriver stuff (most of which is still on stackdriver.com, always causing a confusing redirect and often re-authentication), and it's been similarly underwhelming. We use Prometheus with Grafana, and StackDriver seems pointless in comparison.

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

#190

Post by atombender »

deanCommie wrote: post #22

I'm always surprised that comparisons like this with AWS miss the fundamental philosophical approach of the cloud offerings. AWS is "infrastructure as a service". Hosts, network switches, load balancers - things that historically cost an arm and a leg, but they could virtualize. Add some elasticity and auto scaling, and you've got the foundation to build anything else on top. The hyper-specificity of SQS vs Kinesis,…

Google may have started with AppEngine, but that's not how it is today.

Google now has a line-up of products directly competing with equivalent AWS services: VMs (Compute Engine), queueing (Pub/sub), key/value storage (GCS, which even has S3 API compatibility), SQL databases (CloudSQL, Spanner), Redis, document storage (Google Datastore), distributed file system (Filestore, like EFS), big data store (BigQuery), etc.

Post reply on HN