Why would one choose GCP over other cloud providers?(xmsxmx.com)
xmsxmx.com
Why would one choose GCP over other cloud providers?
http://www.xmsxmx.com/gcp-advantages-benefits-over-aws-azure/
6 comments
No noisy neighbours.
Counterpoint "GCP documentation is terrible"
Example:
Today I was auditing GCP firewall rules for a client. It's sort of hard to find orphaned rules so I asked on stack overflow. A kind Googler replied, "it's not built in but I whipped up this thing in node to do it". Great! So I clone his example code, install the deps, gcloud auth at the command line and run it.
Oh no! auth failed.
"Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the cloudasset.googleapis.com. ...Use a service account.
https://cloud.google.com/docs/authentication/"
Great, I read that document. Big, long wordy thing. Nothing about service accounts. I see this other one in there that looks promising. https://cloud.google.com/iam/docs/overview No dice, but I do see mention of service accounts in the nav bar. https://cloud.google.com/iam/docs/service-accounts Close, but ultimately not what I need, try two more. Now I'm 5 documents deep and I'm honestly wondering what I'm doing.
I finally piece together that I need to create a service account explicitly grant it a role download credentials export the credentials location
How hard would it be to write that in one place and call it something like "How to use service accounts (and why)"
But wait! It still doesn't work, gotta activate the Cloud Asset API (have you ever tried to use an AWS service and failed because the something something api wasn't active yet? No you haven't) Ever run into an api usage limit? That's a fun one. Imagine that api is the one you're using to report problems with your production cluster. Good luck getting that fixed in a reasonable period of time. I ended up just waiting 24 hours for it to reset. But I digress.
Ok, so I do all that. Only to figure out that's not quite what I need so now I'm chaining together some gcloud commands, filtering output, making tables, sorting in vi.
I wind up with a 192 line spreadsheet and a lot of manual work remaining to work through them all. Maybe this stuff is available in the Google Security Center, but I can't see it because it's helpfully hidden under the organization permissions not the project permissions. Great.
You know how you do this on AWS? This very important security thing that you should do quarterly if not more often? You click on trusted advisor, it shows you the unattached security groups you can safely delete, it advises the ones you should lock down. Done.
Don't get me wrong, Google network infrastructure is generations ahead of AWS. But it's all useless if you can't get it working right and GCP documentation is worse than nothing at all. So good luck getting things working right.
Also when things are just a bit more complicated the odds are good that even smart, capable people will screw something up (yes I found some problems during my audit today, no I don't think those problems would have been there if the client had deployed on AWS or Azure)
In conclusion think twice before choosing GCP
Great, I read that document. Big, long wordy thing. Nothing about service accounts. I see this other one in there that looks promising. https://cloud.google.com/iam/docs/overview No dice, but I do see mention of service accounts in the nav bar. https://cloud.google.com/iam/docs/service-accounts Close, but ultimately not what I need, try two more. Now I'm 5 documents deep and I'm honestly wondering what I'm doing.
I finally piece together that I need to create a service account explicitly grant it a role download credentials export the credentials location
How hard would it be to write that in one place and call it something like "How to use service accounts (and why)"
But wait! It still doesn't work, gotta activate the Cloud Asset API (have you ever tried to use an AWS service and failed because the something something api wasn't active yet? No you haven't) Ever run into an api usage limit? That's a fun one. Imagine that api is the one you're using to report problems with your production cluster. Good luck getting that fixed in a reasonable period of time. I ended up just waiting 24 hours for it to reset. But I digress.
Ok, so I do all that. Only to figure out that's not quite what I need so now I'm chaining together some gcloud commands, filtering output, making tables, sorting in vi.
I wind up with a 192 line spreadsheet and a lot of manual work remaining to work through them all. Maybe this stuff is available in the Google Security Center, but I can't see it because it's helpfully hidden under the organization permissions not the project permissions. Great.
You know how you do this on AWS? This very important security thing that you should do quarterly if not more often? You click on trusted advisor, it shows you the unattached security groups you can safely delete, it advises the ones you should lock down. Done.
Don't get me wrong, Google network infrastructure is generations ahead of AWS. But it's all useless if you can't get it working right and GCP documentation is worse than nothing at all. So good luck getting things working right.
Also when things are just a bit more complicated the odds are good that even smart, capable people will screw something up (yes I found some problems during my audit today, no I don't think those problems would have been there if the client had deployed on AWS or Azure)
In conclusion think twice before choosing GCP
There is no doubt that AWS is more mature. You make few points:
- poor documentation
- no security auditing tool
- API limits.
In my experience 1 and 3 are true for AWS as well. AWS has automated tools to detect things but to say that GCP does not have any such offering is not true. It may not be automated and that goes to the larger point of AWS being more mature.
https://cloud.google.com/vpc/docs/firewall-rules-logging https://cloud.google.com/network-telemetry
Developer experience and User education is where GCP needs a lot of catch up to do.
In my experience 1 and 3 are true for AWS as well. AWS has automated tools to detect things but to say that GCP does not have any such offering is not true. It may not be automated and that goes to the larger point of AWS being more mature.
https://cloud.google.com/vpc/docs/firewall-rules-logging https://cloud.google.com/network-telemetry
Developer experience and User education is where GCP needs a lot of catch up to do.
Oh lordy. The GCP docs. I straight up ignore them most of the time and just search for relevant guides elsewhere. So much of what Google puts up is marketing fluff, high-level descriptions, or at best a description of the happy-path to doing something.
The most galling thing is GCP support. I'm on a team which pays for google support and it is by far the most lax, useless nonsense I've ever encountered. They are literally no help.
The most galling thing is GCP support. I'm on a team which pays for google support and it is by far the most lax, useless nonsense I've ever encountered. They are literally no help.
Personally I feel like AWS has forever poisoned the well for me on those but I get the appeal.