[deleted]
Google Cloud Platform – The Good, Bad, and Ugly
41–50 of 202 posts
Re: Google Cloud Platform – The Good, Bad, and Ugly
#42Although 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.
I haven't tried this myself, but could you have your client(s) get around this via multipart upload?
Re: Google Cloud Platform – The Good, Bad, and Ugly
#43Although 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.
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.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#44Hey 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…
A lot of what he wrote is on point.
For example:
> I have reported bugs/clarifications against AWS docs and got prompt feedback and even requests for clarification from AWS team members. This has never happened for my comments submitted against Google’s documentation.
I always submit "feedback" (for the last 2 years), but the lack of changes in the docs make them seem to disappear into a black hole, so I stopped doing so.
Would be great if the docs for GCP were on GitHub (like the K8s, and now AWS, documentation) so we can at least see that docs are being worked on and iterated, and share/validate common issues and suggest fixes.
Minor things like this also create a lot of developer confusion in large user orgs:
> The API libraries and tools are spread across several GitHub organisations including GoogleCloudPlatform, Google, and possibly others, which can make it a little difficult sometimes to track down the definition of something.
> It would be easier if I didn’t need to think about this API access
Everything in the "ugly" is spot on.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#45Earlier quoted context omitted.
Terraform is great because it lets you treat infrastructure as code, but I don't think it makes any promises about cloud agnosticism. In fact it's the opposite, each provider is specific to the service that they are offering. Rather than Terraform offering a lowest common denominator set of resource definitions, each provider can be designed to work in a way that most naturally maps to their offerings and API. In the…
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.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#46> Another service that would be very handy is a hosted etcd/Zookeeper service for service discovery, consensus, leader election, and distributed cron jobs.
Look at GKE :)
Re: Google Cloud Platform – The Good, Bad, and Ugly
#47My main bugbear with GC is the fact their api’s seems to be written with no regards to usability/consistency/stability from a dev perspective.
For instance I wanted to create a project progmatically a few months ago - so check out the docs. Ok v1 of the api has it...wait there’s a v2, it’s been completely removed. where has it been moved to...absolutely no clue. so what am I using now? A deprecated api?
Re: Google Cloud Platform – The Good, Bad, and Ugly
#48Hey 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…
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...
Re: Google Cloud Platform – The Good, Bad, and Ugly
#49Hey 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…
A lot of what he wrote is on point. For example: > I have reported bugs/clarifications against AWS docs and got prompt feedback and even requests for clarification from AWS team members. This has never happened for my comments submitted against Google’s documentation. I always submit "feedback" (for the last 2 years), but the lack of changes in the docs make them seem to disappear into a black hole, so I stopped doin…
Thank you for the feedback. While I can't share specific details, we are always looking for ways to improve the documentation, bug reporting, and feedback process.
I also totally agree that these little things matter, even for small organizations. An incorrect or incomplete piece of documentation can cost someone hours or days, not to mention the emotional cost. Rest assured that we are working to make the experience better.
Re: Google Cloud Platform – The Good, Bad, and Ugly
#50Hey 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…
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 going to share your feedback about Stackdriver with our product team as well. Thank you for that!