
Google Cloud Platform – The Good, Bad, and Ugly - dantiberian
https://www.deps.co/blog/google-cloud-platform-good-bad-ugly/
======
magsafe
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/occasionally connected sync scenarios).
Firebase Cloud functions allowed me to convert an AWS Elastic Beanstalk
project into a 100% serverless architecture, which basically runs itself with
no ongoing maintenance or scaling required. It took a significant amount of
work off my shoulders. Once I had a positive experience with Firebase, I
started poking deeper into the Cloud Console. I realized I could use App
Engine, Compute Engine and various other services, which all made perfect
sense as "upgrades" to the core Firebase project. I've now migrated the
backends of 2 existing, popular iOS apps from AWS to Firebase+GCP. Kudos to
the Google team for making Firebase perfect for my needs, and the overall
Cloud platform.

~~~
madrox
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.

~~~
ProblemFactory
> 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.

~~~
dragonwriter
> 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 are using a public cloud data center for private data with regulations
around authorized access, there is basically 100% chance that people without
access authorization have physical access to the servers and their disks in a
manner where there is no direct knowledge of the data owner of what occurs,
which makes the threat of “unauthorized person gains physical access to the
hard drive and steals data” _greater_ , not less, than “a server in your
bedroom” (or, more relevantly for corporate use cases, in a corporate data
center for which you control physical security.)

------
neya
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 traffic.

* There is an on the fly image resizing service, which means, you don't need to run complex imagemagick setups on your machine, instead you can simply call your image with parameters appended Eg. - /my.jpg?size=120x80 and it will be resized on the fly. And it's pretty damn fast, too.

* If you're also using Cloud SQL, you can directly let your app talk to it without whitelisting IPs or even using the proxy, just using sockets.

* You can lock your app under what google calls IAP, a login layer that allows only authorized users to access your app. IF you're building prototype for clients, it's a no brainer and saves you from adding custom auth. ([https://cloud.google.com/iap/docs/app-engine-quickstart](https://cloud.google.com/iap/docs/app-engine-quickstart))

* The development experience is superb, and has gotten better in the last 2 years.

For the record, I tried AWS ElasticBeanstalk recently and it has a lot of
bugs, especially with the new interface changes, so I kept coming back to
AppEngine. Seriously, if you're doing a startup in 2018, there is no reason to
not use AppEngine.

~~~
dantiberian
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.

~~~
neya
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.

~~~
dantiberian
Yeah, the issue (which I didn't explain well) is that Deps is a Maven
repository and needs to speak the Maven protocol. That makes it difficult to
do the ACL signing for direct uploads, especially if I want to make it clean
for users configuring it.

~~~
stefano
You can have the client upload to a cloud storage bucket, then notify the
server that the file is ready. Upon receiving the notification, the server can
start a background task that reads the file from the bucket and uploads it to
the Maven repository.

It's a few extra steps for something that should be simpler, but it's
workable.

~~~
dantiberian
The client in this case is Maven, SBT, Leiningen, e.t.c., so I don't think I
can get that kind of control over how Maven would upload the files.

~~~
foota
I'm curious, could you use a 307 redirect to redirect the user agent to a
signed upload URL?

------
sethvargo
Hey 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/an-introduction-to-f...](https://devrel.net/developer-
experience/an-introduction-to-friction-logging)) to help our product and
engineering teams identify and fix any rough or unexpected edges in our
offerings. This feedback will be valuable to our teams the same way a friction
log is valuable.

Thank you again for taking the time to write this up!

~~~
optimusclimb
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 retrieves the data.

Though...why doesn't constructing the object fetch the properties? And if it
doesn't, why don't you just write some sentences somewhere telling people the
general flow they should expect for how to interact with the API?

From my experience with all other GCloud docs, the answer is - because Google
couldn't care less if their customers can figure out how to use their
products. You write some minimal API docs on functions, MAYBE give one example
of doing one specific activity, and then it should be OBVIOUS how to do the
rest.

Having used both - would never, ever choose to use GCP over AWS if given the
choice - and the main reason, aside from any technical differences - is that
one company seems to care about what the experience of using their product is,
and the other just doesn't.

~~~
sethvargo
Thanks for sharing your experience. This is definitely not the feelings we
want users to experience. If you remember, could you share the documentation
page(s) you were on? I'll make sure they are updated to reflect the proper
fields and steps to take.

We do care deeply about our users' experiences with both GCP and the GCP
ecosystem. Feel free to send me specific areas where you've experience pain in
the past and I'll get them addressed (email is the same as my handle - at
google - dot com)

~~~
optimusclimb
Thanks for the response. See my response to bduerst in this same thread - it
was that page.

Also to be clear - I don't think this particular example I gave is the end of
the world/egregious - I just used it as representative of the fact that the
general pattern I've seen of the docs following where details are explained,
but the "obvious" bits of simple usage are not discussed.

------
gingerlime
This was one heck of a rundown of different GCP options and problems. I
haven't used as many services as the OP, but definitely most things that did
overlap pretty much echoed my own experience.

Specifically, support and billing.

We've used Gold support for a while, and our experience wasn't great. Pretty
much the same as the OP described with Silver. Perhaps response times were
slightly faster I imagine, but I would be surprised if quality was any
different.

Regarding billing, we've been going through some kafkaesque cycle there trying
to set invoiced billing. I've filled a form on their invoiced billing page, a
sales contact talked to me on the phone and I explained everything. She then
sent an email asking me to fill another form, which I did, and then got
contacted by another billing team who basically sent me to the original page.
I explained the situation and they just didn't really seem to care or
understand what's going on. They then tried to arrange a call, but missed two
schedules that I've set, called the wrong number, wrong country code... Not
sure where this phone call would lead. Absolutely mind boggling experience
there. Teams don't talk to each other. They send the customer around running
in circles. It's amazing that it's happening with one of the most
sophisticated companies in the world in the 21st century.

~~~
Drdrdrq
I am in a process of choosing between AWS and GC, and the reason I'm leaning
towards AWS is that this is Amazon's primary business. They care about it and
they know how to deal with customers. Google on the other hand... They could
decide tomorrow that GAE is no longer something they want to deal with, and
shut it down. Not likely, I agree, but their incentives and mine are not
aligned.

~~~
swozey
I'm not with GCP but I'm fairly closely connected to its technical staff and
user community and a heavy consumer and have been so for about 4 years.

It gives me a somewhat unique perspective where I'm happy to give them lip
when they need it and they have at times and they also ask for my input fairly
frequently. In my opinion they are all in on GCP and it's definitely going
nowhere but up. They've been on massive hiring sprees and it's to the point
that when I visited them at the Googleplex a few months ago a bunch of their
campus buildings were now labeled as Google Cloud buildings.

Obviously logos can be removed and maybe it will say Android/Allo/whatever in
3 years but the team is incredible and they seem laser focused on growing the
platform. You can go through their blog
[https://cloudplatform.googleblog.com/](https://cloudplatform.googleblog.com/)
and the improvements they're making and the pace at which they're making them
is pretty great.

I've used them for ~4 years so I've definitely had frustrations, especially
prior to them reorganizing their Support/Account Management structure about
6-12 mo ago (I do k8s so I interact with this side of things as infrequently
as possible).

This is a huge money maker for them and I think they're doing a great job
albeit they still need to focus on their soft skills (support, billing pains,
etc).

I have migrated a few companies from AWS to GCP and they've all been happy. If
the day ever comes to leave GCP I have no problem making that call; I'm not
handcuffed to them. Hopefully they just continue to improve.

~~~
smueller1234
Nit: There's actually an entire campus that was built for Google Cloud, not
just a few buildings.

~~~
swozey
Ha, proof I don't work there! :)

------
madrox
I've been running a production project in Google App Engine for three years
with six figure active users and can mostly agree with this. A few comments:

1\. Stackdriver gets a bad rap. Maybe there are better solutions out there,
but it hasn't been our weakest link. It's gotten very expensive, though.

2\. Google recently deployed a new HTTP load balancer that is way better than
the old one.

3\. Instance usage on app engine is a little opaque and very hard to tune. A
lot of it is trial and error.

4\. Cloud SQL is garbage and the author is being generous if anything. Haven't
had a chance to try Spanner, but it seems a lot better. App Engine + SQL has a
lot of little hidden gotchas that are impossible to debug. I'd never recommend
anyone use it in production.

Google Cloud has come a LONG way, and one of the biggest reasons we continue
to invest in it is they keep improving based on feedback. Their product team
is very engaged. Their IAM additions, improved load balancing, and additional
availability zones have been huge for us.

~~~
sipos
Can you elaborate on what is wrong with Cloud SQL? I have next to no
experience with it GCP Cloud SQL, but use AWS RDS a lot.

~~~
madrox
Cloud SQL itself is fine...it's just hosted SQL. That said, there is a lot of
google-bespoke code for interfacing various parts of their cloud with it.
Cloud SQL Proxy has a lot of gotchas and hard to debug. For example, the per-
instance connection limit between app engine and cloudsql is 5, and it's
impossible to know how you're bumping against that. Tuning is a frustrating
process, and google support hasn't been too helpful.

~~~
laixer
The limit was never 5. It used to be 12 and now it's 60.

------
jrockway
> Sometimes when browsing documentation for a service or API you will find
> that the old way is deprecated, but the new way that they recommend you use
> is still in beta or alpha (!).

Familiar.

~~~
clhodapp
"Beta" is kind of an awful purgatory state on GCP. We all know that most of
their beta stuff is actually really well-tested and stable (it's even
mentioned in this article). They also know it themselves and seem to assume
that people will be willing to start using their products when they are in
beta. However, they have an ill-advised blanket policy that beta products are
not covered by SLAs, which ends up meaning that no responsible decision-maker
wants to build anything in production on top of anything tagged "beta". In
many ways, you get forced to treat beta in exactly the same way as alpha even
though you know that it's actually much more reliable. I strongly believe that
Google and its users would be much better off if Google used beta to mean
"SLA'd but with documented feature gaps and a shortened deprecation period"
and kept stuff that they are not willing to SLA in alpha.

~~~
wikibob
I totally agree, this is a serious problem. Because even if you understand
that they mean “hey it’s Beta but it’s fine for production”, if you choose to
use it and it breaks, all blame will point back to you for making an unwise
choice.

There is a terrific explanation of the difference between Alpha, Beta, and
Stable in the Istio project [0].

Istio was started by GCP, so while this isn’t officially Google’s definition I
imagine it’s peobably the same.

It basically says, Beta is mostly usable in production, but things might
change in the future that require work from you to upgrade.

[0] [https://istio.io/about/feature-stages/](https://istio.io/about/feature-
stages/)

------
i0exception
I'm surprised that GKE is not included in the list of "Good"s. Managed
kubernetes has been a game changer for us.

~~~
dantiberian
I've just updated the post to make it clearer that I'm only talking about
services that I used. GKE definitely looks promising, but I haven't used it so
I can't give an opinion on it.

~~~
nvarsj
I will add from my personal experience that GKE has come a long way, and it is
probably the best managed K8s experience now. Still has some warts - a lot of
the stuff you'd expect out of the box is still beta, or preview. And until
this year, I wouldn't have used GKE for any significant installs, at least not
without a really good support contract.

------
penland
I've been jumping between AWS and Google Cloud ( with a bit of Digital Ocean
sprinkled in ) for the last several years. I chose Google as our cloud
platform when we founded our company last August. I could War and Peace a
bunch of things but that article does a very nice job in the details. Instead,
I'll give a one liner:

AWS is to Linux as Google Cloud is to FreeBSD. "Rock solid performance and
everything is exactly where you think it should be"

~~~
skywhopper
Your analogy is confusing me. On GCP, none of the tools have all the features
you expect?

------
bazza451
My 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?

------
pbrumm
well written.

Things I would add to the Good side.

\- ability to commit to multi year cpu/ram without upfront costs

\- they can live migrate your vm to new physical hardware, so no need to have
random reboots of your instances

\- https load balancers allow traffic around the world to enter google network
closest to user, this reduces handshakes and reduces comcast like outages to
affect users.

the above greatly decrease my stress.

~~~
ebikelaw
I guess that closeness to user got eliminated from the “good” list since
Google’s FELB is serving 502 to this author’s customers.

~~~
dantiberian
They did eventually stop serving sporadic 502's, I've updated the post to make
that a bit clearer.

~~~
esseti
OP: for the 502 problems give a look at this
[https://github.com/kubernetes/ingress-
nginx/issues/1396](https://github.com/kubernetes/ingress-nginx/issues/1396)
[https://github.com/kubernetes/ingress-
gce/issues/34](https://github.com/kubernetes/ingress-gce/issues/34)

I run into the same problem while ago. It may solve your problem as well.

------
ciguy
The article mentions Terraform workspaces and their limitations (Not Google
Cloud related at all). The way we get around this is to have separate variable
files for each environment. The master file contains sensible defaults and
then those get overridden by the environment specific files.

This is the only sane way to manage variables in terraform right now IMO. It
does require that you specify a file when you run it, but that's somewhat of a
bonus as it forces you to be explicit about the environment you are running
against. You shouldn't really be running Terraform locally anyway so it's all
handled by the CI server in most situations.

~~~
sethrin
Why should one not run Terraform locally?

~~~
outworlder
Not the parent, but I share the same opinion.

You totally can run locally, provided you are a single developer in your
project. Once you start collaborating, you need this to be in a CI server or
similar. Make it in such a way that the code is guaranteed to be properly
versioned, taking the latest from your 'production' branch, as you can run
into a situation where you are running terraform based on local changes which
are not in version control, by accident or on purpose. Which now means that
the state no longer conforms to the latest TF scripts, and this will come back
to bite you. This also forces you to provide any settings as part of your CI
job, not a one-off command in the CLI. It also give you auditing, and many
other benefits.

But the most important piece of advice I can give is: no matter what your
particular circumstances are, what your project size is, your Terraform skill,
or whatever other variable, _always use a Terraform remote state_ , with
whatever backend you are most comfortable with. No exceptions. Even if you are
running locally, I don't care. Unless you are doing testing while developing
the scripts (and I'd argue even then), there is no reason to use a local
state, ever.

~~~
ciguy
Agree 100% with all this.

------
andypants
The ugliest: no ipv6 anywhere except the load balancer.

~~~
ggm
Came here to check if this bothered others as much as me. Not disappointed.
Considering how strongly other arms of google get Ipv6, this is one of the
saddest failures they have.

------
scarface74
I keep hearing how great Terraform is because it allows you to treat
infrastructure as code in a cloud agnostic manner. But every time I see a
Terraform script, it's tied tightly to AWS's infrastructure -- including
Hashicorp's own examples.

~~~
sethvargo
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 to work
there), but we have a lot of documentation and examples in the Google bits. If
there’s a specific thing you think is missing, I’d be happy to help address
it.

~~~
briffle
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, stable betas).. Kuberenetes deployments have
been out of Beta for at least 6 months, and no movement on the kubernetes
provider

~~~
briffle
I should have included this earlier: [https://github.com/terraform-
providers/terraform-provider-ku...](https://github.com/terraform-
providers/terraform-provider-kubernetes/issues/3)

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

~~~
sethvargo
:) 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.

------
yohann305
my very ugly experience: For a mobile app, the cost of storage access
bandwidth (Google Storage) for a 30 second video will cost you more than the
profit you can make from ad impression (CPM/CPC) using Google Admob, making
any video-based business unsustainable using Google's ecosystem.

Note: If you work at Google, you might want to pass this message up the chain,
thank you.

PS: i've played with all types of admob ads to try to make the system
profitable, even the IN-YOUR-FACE interstitial ad that everyone hates (even
Google themselves hate it, they are limiting its use)

PS #2: Google Admob has also removed the ability to create native ads.

~~~
surajrmal
This is to push you towards CDNs. The main data centers cannot scale
appropriately to serve high bandwidth applications, and aren't meant to.

~~~
krn
I am not sure why this was downvoted. Isn't it true, that cloud storage
service is supposed to be used for _cloud storage_ , and content delivery
service is supposed to be used for _content delivery_?

~~~
tejohnso
Media content storage _and delivery_ is an advertised use case [1]

> ...highest level of availability and performance is ideal for low-latency,
> high QPS _content serving_

And the cost using Google Cloud CDN isn't necessarily going to be a major
improvement over Google Cloud Storage. Egress cost is similar depending on
usage, plus you pay for cache fill and api calls.

[1] [https://cloud.google.com/storage/use-
cases/](https://cloud.google.com/storage/use-cases/)

------
pow_pp_-1_v
Reading the comments here a persistent theme seems to be that the
documentation is lacking. Something that might help is creating a "dog-
fooding" team mostly filled with interns. This team will be responsible for
creating samples with the public APIs. Why Interns? Because they will move on
to better things around the time when their brains learn the patterns required
to navigate the Google cloud API efficiently.

~~~
wikibob
Yes! The documentation problem is NOT complex to solve. I would love to use
GCP on more projects but the docs are embarrassing.

Are they trying to get engineers to write the docs rather than hiring
professional technical writers?

Truly baffling.

~~~
bus_error
[I'm a technical writer at Google working on Cloud documentation]

Thank you for the constructive comments regarding GCP and in particular
documentation; we are working on addressing the points raised.

GCP has a dedicated tech writing team which is growing (we're hiring!) and the
documentation is written by tech writers. We work with our colleagues in
developer relations (developer advocates, developer programs engineers), UX
and the software engineers who created the product.

All that said, we know our documentation is not perfect and are constantly
working to improve. To that end if you see something that is broken/incorrect,
please file a bug (the "SEND FEEDBACK" link in the top right of the
documentation page is a bug submission form). We love to hear from users and I
can assure you docs bugs do not get routed to /dev/null (we have a bug SLO,
just like our SWE colleagues).

As a more general tech writing comment, documenting large, fast growing
distributed systems such as public clouds is tricky. There's a lot more to
documentation than just writing up instructions, such as thoughtful
information architecture. It's a challenge that we, and I'm sure our
counterparts at AWS et al., are grappling with.

As tech writers, we wince when we see errors in our work and feel pain when
users are not able to enjoy the product/service as intended due to issues in
documentation. The whole developer relations team (DAs, DPEs and tech writers)
proactively try and catch these mistakes but of course, we miss some. It is
nice to see users feel so passionately about documentation, so please let us
know where we have made mistakes and we will fix them and try harder next
time.

------
ksajadi
This is a very good evaluation. We were running on AWS for 3 years before
moving to GCP and have the same experience. To make up for some of the
shortages we replaced some parts with the following: \- Monitoring with
Datadog \- Container build and deployment with Cloud 66 Skycap and Habitus \-
Support: well, I simply wish if Google Support was better or at least they had
a more proactive status page update policy.

------
deanCommie
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, for example, comes out of the same
philosophy: Provide the infrastructure, and let customers figure out what to
build on top of it.

Google, meanwhile, started with AppEngine - run your apps in the cloud without
concern for the hardware. AWS's equivalent is Elastic Bean Stalk - more than
one layer of abstraction higher than the default offerings.

~~~
atombender
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.

------
fredliu
I see lots of evaluation of GCP, or comparison between GCP vs AWS recently.
But I don't see as many for the Azure platform, although Azure being the 2nd
in the cloud provider market, and even closing on AWS in market share. Anybody
has any insights on this?

~~~
halbritt
I've used Azure a bit and it's been pretty painful for the most part. There
are three, maybe four identity management systems (Azure native, MS Live,
Hosted AD, others?). Working with the SDKs and doing programmatic
authentication was painful.

I did a fair bit with AKS. It had a lot of shortcomings that would take a
while to go into. They ended up suggesting I use ACS-engine.

There are some products that are neat, that I haven't really used at scale,
but seem good. Most of the bigdata stuff is pretty legit based on my limited
usage.

The customers of my employer are large enterprises. Azure definitely has
penetration there. I only have a small sampling, but many of them end up
leaving Azure for AWS.

None of them are really considering GCP.

~~~
nunez
Could you go into it? I’ve kept hearing good things about AKS, but my
experience with their VM service left me skeptical of those claims.

~~~
halbritt
Here's a list of things from January of this year:

    
    
      - when scaling nodes, didn't get the desired count
      - creating and deleting clusters takes a while (30 minutes)
      - cluster operations get stuck in a loop
      - disappearing node did not bring up a new node
      - external management setup was difficult (GKE assigns publicly reachable IP by default)
      - changing SSH user or key through azcli or GUI didn't work
      - default storage class wasn't set
      - admission control disallows deploying a registry in kube-system
      - nodes randomly go into notready state
      - no ability to add new node pools or modify pool without destroying cluster
    

This was all prior to GA.

------
gingerlime
One other thing I believe is worth mentioning -- and to be honest I was a bit
surprised with -- is the _ecosystem_ around GCP vs AWS.

For example, we were looking for a solid redis hosting service in the EU, and
latency is key obviously. There are virtually none with GCP, but quite a few
with AWS. I'm pretty sure there are other similar examples with other
services.

~~~
ssambros
> we were looking for a solid redis hosting service in the EU, and latency is
> key obviously. There are virtually none with GCP

Google Cloud recently released public beta for Memorystore Redis
([https://cloud.google.com/memorystore/](https://cloud.google.com/memorystore/))
which is a hosted opensource Redis on GCP. It is availabe in europe-west1
region so it might suit your needs.

disclaimer: I am an engineer on Memorystore Redis team.

~~~
ex1710_01
I apologize for bringing up something that is offtopic here but I am really
glad to have read your comment.

Last I read in the docs, Memorystore was not accessible through the AppEngine
Standard Environment, which was rather disappointing to me.

I was wondering if just providing the App Engine Standard Environment with the
Redis instances address and credentials, along with a service account or IP
whitelist for access, would not suffice to be usable there as well. If I'm not
wrong, something similar is done in Flexible Environment according to the
docs.

[https://cloud.google.com/memorystore/docs/redis/connect-
redi...](https://cloud.google.com/memorystore/docs/redis/connect-redis-
instance-flex)

Thanks so much!

~~~
ssambros
Unfortunately that is not possible at this moment. Without going into details:
Flex is running on the same cloud infrastructure as Memorystore that it why it
is possible to establish networking between them. This is not true for the
regular AppEngine.

~~~
ex1710_01
Thanks so much for the reply, it saved me a few hours of trying it out at the
very least! Of course, I hope there is support for Memorystore on App Engine
eventually. Thank you.

------
willcodeforfoo
Seconding the issues on the Load Balancer and 502s. We moved our app there
earlier this year to take advantage of GKE and just sort of put up with random
502s (especially during deployments, which are supposed to be zero-downtime).
We contacted Google Support but they were unable to help and said that yeah,
some percentage of dropped requests is fine. I suppose it's something with our
Rails app or configuration, but no one was able to help and I decided to stop
wasting time trying to fix it.

They have more-or-less gone away now but several months later it leaves me
with very little confidence in GLBs and quite scared to change anything
around.

------
jjjjoe
Hey, I work on public-facing support for GCP. Given the point that it's hard
to see what mailing lists are available I wanted to point out
[https://cloud.google.com/support/docs/groups](https://cloud.google.com/support/docs/groups)

It's definitely not as well-integrated as AWS' forums, but it's a starting
point.

~~~
dantiberian
Thanks! I've just updated the post with that.

------
nvarsj
This is a great article!

I've used AWS extensively, and GCP moderately.

If you take the thoughtworks style approach, I would classify AWS as "Adopt",
GCP as "Trial".

Google is investing very heavily in GCP, both internally and in sales and
marketing. But, it still feels very much like patchwork. At least when you
compare to AWS - which, while complex, is very consistent, very well
documented, very stable, and performs very well. GCP is also, I believe, a
combination of acquisitions, and this bleeds through with differently skinned
UIs and URLs.

I'd say the big exception to this is GKE. If you're happy with a managed K8S,
there is no comparison to GKE right now. GLB+GKE and you're pretty much set to
handle anything with little ops work, and probably more affordable than
AWS+Kops. Although, I'm not sure what the support story is like.

------
karmaseed
We’re currently having this problem where firebase suddenly stops working with
the main wired internet network. I switch to another internet provider (mobile
wireless) and firebase starts working immediately. This may be something to do
with router settings but has everyone in office confused like hell.

------
char_pointer
Can't stress enough how great Compute is compared to EC2. A lot of the
(enterprise) companies I work with are weary of going all-in on a particular
cloud and prefer to hand-roll open source solutions instead of consuming
cloudy services; the most they'll use is VMs, basic networking and storage
(although GKE seems quite popular as well nowadays). GCP nails this use case
IMO. It's fast to provision, reliable, rarely if ever fails during setup, and
you don't need a separate start-up company to predict your costs. It's very
much quality over quantity though, so whilst this is great and manages to
capture a particular market I do think they need put out way more (perhaps
lesser quality) stuff to stay competitive with AWS and to a lesser extent
Azure.

------
fernandotakai
honestly, stackdriver is the worse.

monitoring, as the author said, is absurd.

but their logging solution is even worse, specially when compared to solutions
like kibana + elasticsearch. i wouldn't recommend stackdriver to anyone.

------
djhworld
I've not used GCP outside of GCP training courses yet (the quality of these is
another matter....), but I did come away thinking the console UX and 'Cloud
Shell' thing was absolutely brilliant.

This post was interesting to me as the training course presenters seemed to
make out that StackDriver was the best thing since sliced bread, but I guess
they have to being Google partners...

------
skywhopper
Interesting take. In my job, the idea that cross project connections would be
rare or that it’s good for all resources in a project to have access to all
others seem a little crazy. I agree it’s a far safer default that AWS’s, but
it’s not _good_.

The biggest wall for me in setting up GCP is that the resources and accounts
are all so tightly tied to personal Google identities. This is unworkable for
me, but I don’t see any clear way around it. We’ve set up our billing account
on a shared account but it becomes hard to work with around personal Google
accounts (even moreso when they are corporate Google Apps accounts). The AWS
IAM identity model makes much more sense to me, but perhaps I just need a new
paradigm for thinking about it. Are there any good resources for relearning
how to think about resource ownership in the GCP model for AWS heads?

------
Havoc
I really like the fact that 1x micro VPS is included in their "Always free"
allowance. A free *nix VPS in the cloud is a pretty awesome deal no matter how
you look at it.

I'm currently hosting websites with it & despite being underpowered it seems
to be hanging on thanks to cloudflare caching.

------
a012
I got hard time while trying to figure out searching and filtering Stackdriver
logs. I'd rather streaming logs with EFK and search with Kibana, Stackdriver
is very basic comparing to it. And also visualizing instance metrics is such a
pain, comparing with with AWS Cloudwatch.

------
lemming
One thing I would love to see is root domain CNAME support (or ALIAS, or
ANAME, or whatever) so I can host a static website on a root domain. It seems
like there's a workaround using CloudFlare, but it would be really nice if GCP
itself supported this.

~~~
folli
I'm not sure I understand what you mean, but does this help:
[https://cloud.google.com/storage/docs/hosting-static-
website](https://cloud.google.com/storage/docs/hosting-static-website)

------
whoisjuan
Most of the AWS complexity issues that the author mentions are actually
enterprise / high-scale features.

Sure, they are too complicated and unnecessary for small operations, but many
large organizations wouldn't even consider a cloud infrastructure provider
without those things (comprehensive permission and identity model, discernible
region and inter-region model, breadth, and depth in computing types, highly
auditable security model, etc...)

I get his points, but all the things he claims are great about GCP are only
great for a one-man shop and not for an enterprise operation.

~~~
azurezyq
Easy-to-use permission control doesn't mean simple. For example, you can
always use off-the-shelf IAM roles provided by GCP, but you can also mix-match
permissions and create your own custom roles.

Also network configuration can be complicated if you track down for the
detailed form.

Any specific feature you're looking for is missing in GCP?

------
tonglil
> 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 :)

------
yandrypozo
Another Bad/Ugly: impossible to remove AppEngine data and application without
removing the whole project, shame on you GCP :(

------
manigandham
This is a good perspective from a smaller user. As said before, the core
platform is technically fantastic with the fastest and easiest compute,
storage, and networking around. Some downsides mentioned already have options
in alpha/beta (like more updated UIs, products like memorystore, filestore).

------
bobbydreamer
App engine - it would be good to have a button to delete app engine instead of
deleting a project approach.

------
estevaovix
Having multiple accounts as best practice has nothing to do with IAM being
complex, it’s about organization and security.

Would you run all your workloads in a single account? A bit messy if you have
tons of resources and people collaborating.

And what if this single account gets compromised?

------
Thaxll
I think the GCP LB is way better than anything you can get on AWS.

~~~
nvarsj
It's also more limited in some ways. People like integrating with
Akamai/Cloudflare for instance, in which case there is little point to GLBs.

------
ernsheong
GCP wins hands down when you need to ssh into your server via mobile on the
go. It has a mobile app. I'm not aware of an AWS mobile app!

~~~
nunez
There is one, but it doesn’t do much

------
lucasjans
Ugly: no VPC secure access to Cloud Functions basically making it worthless to
connect with legacy database systems hosted on GCP.

------
dfischer
+1 Loving Firebase + GCP

------
fierro
article needs a date

~~~
dantiberian
Thanks, I've updated this.

------
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)

------
pdeva1
slightly off topic, but since the post mentions StackDriver Monitoring in the
‘Ugly’ section. Just wanted to point that you can get 100% free high quality
Infrastructure monitoring from DripStat and use it on all your gcloud vms,
thus avoiding that issue completely.
[https://www.dripstat.com/products/infra/](https://www.dripstat.com/products/infra/)

~~~
vageli
Is that your project? You seem to do a decent amount of promotion of it and
Chronon Systems.

For what it's worth, I'd imagine most people would be hesitant to use a free
service for something as critical as their monitoring. Especially since the
first term in the terms of service says the service can terminate at any time,
without notice.

