I find the GCP documentation to be lacking compared to AWS. Specifically while using GCP with Terraform I hit more frustrating nonsense error messages with little to no google hits or undocumented behavior around IAM config compared to my experience doing similar things on AWS.
I'm a technical writing manager on GCP, and we are actively working on improving Terraform documentation. Thank you for bringing up two significant problems with using TF on GCP.
If you are willing (and of course have the time), we would love to hear other issues you - or anyone else who reads this thread - are having with TF documentation on GCP as we try and make things better.
Rinse and repeat - someone complains about cloud provider, a cloud provider person shows up and makes a "we want to hear more about your problems" statement, people reply, they do nothing. How many times has this happened? I'm more disgusted by the farce than by the lack of action.
Don't you have feedback buttons on the docs? What happens to the feedback from those? Please prove you consider feedback before asking people for more of it.
A few months ago I was working on migrating cloud build for a personal project and hit a documentation error. Submitted a correction via the feedback button and it got fixed few days later. To be honest I was a little surprised by how fast it got fixed.
A general issue I have with GCP docs is that they are overly implicit. Often the interaction of two features is implied but not specified. Another issue I have is when implementation details are waved away rather than explained. It adds up to an experience where I am trying to read between the lines of the GCP docs for a feature to understand what is really happening.
AWS docs are the opposite. They are often very long and verbose, but once you read the whole manual, you can be guaranteed to have a good understanding of the service.
My advice for the Google team would be that if you are ever writing documentation and ask yourself “does the customer really need to know about this?”, the answer should always be yes.
This is probably more a request at the compute team/gke teams but...spot management.
For example, managing a spot fleet in AWS via terraform is filled with features and levers I can pull. It's easy to manage basic scale-out/scale-in procedures and allows me to set thresholds.
In GCP, as I understand it, I can only manage a node pool at a basic level.
EDIT: Also, yell at the people who manage the python library.
Can you please update the terraform docs for google batch? In [1] it’s really difficult to know what everything in the json configuration is under the base64encode() call. What levers can I pull? How do I run something more complex than hello world? Do I need my CICD to upload scripts to GCS and have the instance download them at runtime and hardcode that path into the batch script?
It seems as though Google Batch does not have a native Terraform resource. The document in [1] seems like a workaround that leverages the Cloud Scheduler Terraform resource, but submit a job using the JSON configuration. The various fields that can be used in the JSON are within [2]. Regarding using GCS there is an example in [3]. I found more samples in [4]
I had the same gripe when I worked with GCP. Their stuff is exotic, and had weird behaviors in corners, but the docs didn't give you enough context to steer away from them.
However, over the last 5 years or so, AWS docs have gotten worse.
So I guess now that they are both bad I can't complain?
Did they? Do you have an example at hand? We ran into "weird" issues a lot of times with AWS services just to discover afterwards that almost all of them were covered by their documentation.
It was totally our fault and these were also no "hidden" docs.
100%. My experience has been the same. The docs have their shortcomings and I ended up reading through so many Github issues and random blog posts trying to resolve the issues.
From a documentation perspective, AWS is still the best.
Wow I would literally say the opposite. I even use GCP docs as an example for my engineers on how to write proper docs, and did several workshops using the GCP docs as reference. Happy to share the presentation if interested.
Google's support is the worst. Have an issue like those random nonsense error messages, good luck getting it resolved. AWS is complete the opposite. I had an issue Aurora Postgres and got to chat with the product manager of the product.
Google could have the best products on the market but no one is going to use them if the support isn't there.
I was sad when Looker got bought by google. I remember having issues with setting up looker and using their chat functionality and having the CEO of Looker answer my question.
Well, AIUI "reach the front page of HN" was always the only cited way of getting any help with a Google problem, so in that way this is a derivative of that scenario
I've used GCP support on accounts with huge support contracts and enterprise agreements and it's still a bit of a wash if you get good support on your first, second or even third run around the reply button.
At least it isn't (paid) Azure Support - that one is noticeably outsourced to people that sometimes lack basic comprehension for the problem. I once asked about their VPN Gateway and got a random API Gateway response, then nothing for a week, and then a new rep.
Why is GCP a distance 3rd with cloud providers? They used to be second. They literally will throw tens of thousands of dollars of free development to get you to switch. Amazon may give some service credits if you're willing to switch an application over to them. EKS and GKE are on par with each other. So its not technology holding them back.
Honestly, it boggles my mind. Bad marketing seems to be the driving force here.
“Nobody ever gets fired for buying IBM.”
If you've actually spent time building on their platform though, it feels like you're in some sort of inner circle of knowledge. The stuff works, and works really well.
