
Many ways where GCP excels over AWS - DevOpsy
https://medium.com/@nandovillalba/why-i-think-gcp-is-better-than-aws-ea78f9975bda
======
harryparkdotio
As someone that works solely in a GCP environment for work, I couldn't agree
more. GCP products do "just work", but if I had to nitpick, it's that some of
their services don't have complete terraform modules (looking at you IAP), but
outside of that, their pricing is reasonable, documentation is solid, and
we're really happy we ended up going the GCP route.

~~~
kapilvt
As someone who just dealt with the questionable state of the gcp docs, I
couldn't disagree more, afaics there's really no qa on this stuff. to wit, the
official docs for turning on storage bucket uniform access are a missing a
parameter, that we only found after turning on http tracing on gsutil. The
docs themselves are very spread out, and frequently have errors or
inconsistencies (ie use beta v1 of this, v1 of that, and alpha v1 for
different resources in the same service). Unlike aws or azure, none of the
actual api specs (json data) or even the official cli implementation is in a
public repo. For python alone, googlers maintain like 4 different
implementations of the api, 'nough said.

~~~
hodgesrm
I've also had some bad encounters with the GCP docs, particularly around
object storage. That was a while ago and may have been fixed. Early on they
were not consistent with the actual APIs and poorly organized to boot. It was
complicated by the fact that the APIs seem to have shifted.

Amazon overall has done an excellent job on documentation. It's made easier by
the fact that they rarely change API behavior once it's deployed.

------
bweber
This article doesn't even mention one of my favorite tools on GCP which is
Dataflow. It's really easy to build batch and streaming workflows that can be
used for data and machine learning pipelines. It really shows how well the
different services within GCP are integrated, since it's trivial to set up
PubSub or BigQuery as sources and sinks.

------
hodgesrm
Contrary to the claims of this article I'm very skeptical that the admin UI is
much of a success factor when running large applications in public clouds.

Cloud administration is inherently complex. If you are doing anything
interesting you'll be managing configuration through tools like Terraform and
Ansible. Also, if you don't understand virtual networking on your particular
cloud you are going to have problems even there. Any cloud service that gives
you good control over networking is by definition going to require effort to
configure properly.

------
blueblisters
FWIW, I find the AWS UI much better than the GCP interface. AWS _feels_ much
faster to navigate, even though GCP has an SPA-like design, like its other B2B
tools.

~~~
londons_explore
Since all of GCP is available with an API, I'm surprised there aren't third
party dashboards. I'd happily pay a percent or two of my bill for an intuitive
dashboard at a glance. Especially one that kinda fills the gap between
monitoring, alerting, debugging, and manipulating resources.

~~~
user5994461
What you're looking for is datadog. A
metrics/monitoring/alerting/debugging/dashboard solution.
[https://www.datadoghq.com/](https://www.datadoghq.com/).

Try a google image search and you will see some examples. There are lots of
menus and visualization so you obviously want to try the tool for yourself.

------
foobarbazetc
The GCP LB is, honestly, one of the most impressive pieces of software ever
written and unmatched by any other provider.

~~~
weitzj
I could not agree more. Having fixed private IPs on AWS is a pain. Looking for
AnyCast solutions in AWS is not clear to me.

Also I enjoy that GCP has gRPC support.

------
mcdermott
Both AWS and GCP excel over Azure. Many organizations are strong armed into
using Azure as part of their Enterprise Agreements (EA) as part of Microsoft's
predatory tactics (they haven't changed one bit) I couldn't imagine someone
choosing to use Azure if given a choice.

~~~
SgtBastard
Then you’re rather unimaginative - .NET/SqlServer shops are still 2nd class
citizens on both GCP and AWS.

Azure App Services and SQL database arrives a 1-2 punch for enterprises moving
their apps to a PaaS that just works.

~~~
eropple
"Just works", unless you want a working audit log that tells you who rebooted
a service.

Azure is fractally off-kilter.

------
rantwasp
yeah no.

aws excels at giving you the building blocks and making sure those building
blocks work.

unless you’re working at a small scale that’s what you want.

for all the crap aws gets, the documentation is there, the tutorials are
there, the services make sense.

gcp is probably going to be around for a while, but i would not bet the farm
on it.

in the cloud, today, it’s either aws or azure

~~~
dnautics
I agree with your general sentiment, but in terms of UX the article is spot
on.

~~~
rantwasp
sure. the AWS console has been very hard to use since forever. Some may even
go as far as saying that it improved. The UX is not the selling point of a
cloud provider.

~~~
dnautics
disagree. I get the sentiment that in the long run an end-user absolutely
"shouldn't care", because the infrastructure should be code, if the initial
end user onramp sucks (bad UX) then it might give you a negative impression of
the system. This impacts other end users, because if adoption has a negative
first derivative, you could be in trouble in the long run.

but UX goes beyond just clicky bits on the web. It's also stuff like "does
your service take JSON as input and output JSON or XML?". "are critical fields
well-named?", "is documentation for your endpoints well-structured and easy to
comprehend" which, if the UX is poor, makes your IAC much much harder to
reason about when things go wrong.

~~~
rantwasp
i don’t disagree with your points. ux is more than ui. and it’s definitely
harder nowadays to learn about the cloud than it was 5 years ago.

------
gpapilion
I thought this would have mentioned live migration, which honestly solves a
major pain point in aws.

~~~
rantwasp
it does not. if you need live migration your software is poorly engineered.
the only use case for this is a legacy app that you cannot move away from -
but in that case i doubt you’re in the cloud

~~~
docsapp_io
Imagine you running large database workload and AWS say you need reboot
because underlying hardware start having issue.

Live migration can help you in that case.

~~~
rantwasp
1\. use RDS

2\. if you want to run your own you’d better know how HA setups work and you
can lose at least a machine at ANY point in time (not just when AWS warns you
the hardware is failing)

~~~
tbrock
RDS is a joke unless you use aurora. Necessary downtime for a database
upgrade? Try again Amazon.

~~~
rantwasp
what engine are you using? is it in an multi-AZ setup?

~~~
tbrock
Postgres, yes, of course

------
ckdarby
I don't think the author actually has used AWS extensively or in recent times
because almost the whole section on EKS is wrong or out of date.

Just this week I updated an EKS cluster from 1.15 to 1.16 with two clicks.

------
not_kurt_godel
I think a lot of the issues with AWS mentioned here are mainly the result of 2
factors:

1\. AWS having been around longer, and having been vastly bigger and more
widely used than GCP for the entire lifespan of both products. AWS is just
more expansive/evolved from having piled on more features for more customers
over more time.

2\. AWS virtually never makes backward-incompatible changes. Every feature of
every service and every version of every API since its inception is still
functional and presumably will remain that way forever (with a _very_ minimal
list of exceptions). So while it's certainly easy to imagine how the entire
thing could be streamlined from a blank slate, it's just not how AWS operates.

Meanwhile, Google is absolutely notorious for wantonly EOLing products; see:
[https://killedbygoogle.com/](https://killedbygoogle.com/). Besides the
extensive list consumer products (RIP Reader), there are quite a few examples
of APIs and cloud services that have been axed. I'm not very familiar with
how/if GCP specifically has been impacted by this trigger-happy EOLing, but
frankly I think you'd have to have a huge appetite for risk to trust that GCP
is not going to pull the rug out from under your business on a whim.

The upside of the never-make-backwards-incompatible-changes approach is that
as a customer, I don't have to worry about proactively monitoring for breaking
changes to my applications/infrastructure and pre-emptively emergently
refactoring/re-architecting them to avoid downtime. I have various little AWS
CLI scripts that have been running untouched for years, and they still work.
That's a tremendous timesaver and cost-saver whether you're just doing side
projects for fun or running enterprise IT.

The downside to this approach is that the product as a whole is an ever-
growing spiderweb-snowball of complexity, by design. While some new
services/features get added as simplified alternatives to existing offerings
(i.e. Amplify, Lightsail), they still exist in an ocean of cruft, and it takes
some level of expertise just to be aware of their existence and tease out
exactly what aspects they simplify and how they interface with the rest of the
ecosystem. If and how AWS resolves this problem dynamic over time remains to
be seen; it certainly is a pretty big Catch-22 from a high-level perspective.

So, in short, while GCP is inarguably a more streamlined and user-friendly
platform today, it is a bit naïve to make a blanket comparison to AWS on this
basis. There are good reasons why AWS is the way it is, and I wouldn't
necessarily bet on GCP maintaining its comparative sleekness over time as it
may eventually fall prey to the same problems. (Nor would I bet against them
avoiding/solving these problems either - there are a lot of very smart people
at Google.)

~~~
CraftThatBlock
Has Google EOL any Cloud products? I don't remember any being shutdown
recently at least. Since these are money-making products (unlike maybe other
good customer-facing products), there's a lot less reasons to shut things down
IMO

~~~
kapilvt
yes... albeit its an odd one.. a few months after the switch out from Diane to
Thomas on lead exec.. they shutdown google hire which was in the gcp portfolio
[https://www.theverge.com/2019/8/28/20837004/google-hire-
next...](https://www.theverge.com/2019/8/28/20837004/google-hire-next-tool-
shut-down-service-jobs-hiring-recruiting-inbox-allo)

afaics its called cloud talent in the console now

~~~
not_kurt_godel
Even a small thing like that is a great example of how Google and AWS treat
backwards compatibility fundamentally differently. AWS _really_ doesn't EOL
things, no matter how 'minor' the impact would be. Look at SimpleDB - it was
launched in 2007 and has very clearly been deprecated in favor of DynamoDB[0].
It's not even in the console(!). Yet, it's still operational and usable with
the AWS CLI. Everything about it screams "could have been EOL'd years ago",
yet AWS dogs on in supporting it and everything else it's ever released until
the end of time.

[0]
[https://en.wikipedia.org/wiki/Amazon_SimpleDB#Relationship_t...](https://en.wikipedia.org/wiki/Amazon_SimpleDB#Relationship_to_DynamoDB)

------
uyuioi
The CDN is worse. S3+cloudfront is easy for serving assets. The google CDN
version is so expensive with the load balancing.

